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ABSTRACT 


This  thesis  extends  the  multi- computer  real-time 
executive,  MCORTEX.  The  multiple  cluster  system  RTC*  (Real 
Time  Cluster  Star),  consisting  of  clusters  of  single  board 
computers  (INTEL  iSBC  86/12A),  which  are  connected  via  an 
Ethernet  Local  Area  Network,  serves  as  a  hardware  basis  for 
the  implementation  of  extended  MCORTEX. 

The  extension  upgrades  MCORTEX  to  system-wide 
synchronization  and  general  data  communication  between  any 
processes  in  the  system.  An  intercluster  shared  memory  model 
is  developed,  that  partially  replicates  intracluster  shared 
memory,  such  that  shared  data  replication  is  minimized  and 
the  system's  processing  speed  is  maximized. 

This  implementation,  by  transmitting  produced  shared 
data  to  all  consuming  clusters  as  soon  as  possible  after 
production,  guarantees  that  only  cluster  local  hits  occur  in 
the  system.  Shared  memory  space  is  used  efficiently  by 
transmitting  shared  data  to  consuming  clusters  only,  and  by 
the  ability  to  store  shared  data  contiguously  in 
intracluster  shared  memory. 
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I.  INTRODUCTION 

A.   DISCUSSION 

1.  General 

The  goal  of  this  thesis  is  to  extend  the  existing 
version  of  the  distributed  multi- computer  real  time 
executive  (E-MCORTEX)  in  order  to  provide  systemwide 
interprocess  data  communication. 

The  existing  MCORTEX  version  was  provided  by  David 
Brewer  in  December  1984  [Ref .  1] ,  and  contributes  to  the 
research  work  done  by  the  AEGIS  Modeling  Group  at  the  Naval 
Postgraduate  School  (NPS). 

The  objective  of  this  project  group  is  research  on 
time  critical  processing  required  by  modern  anti-air  warfare 
(AAW)  systems.  The  project  group  chose  the  AN/SPY-IA  phased 
array  radar  processing  unit  of  the  AEGIS  weapon  system  due 
to  its  challenging  time  critical  processing  demands.  A 
further  fundamental  objective  of  the  AEGIS  Modeling  Group  is 
to  use  off  the  shelf  components  within  the  AEGIS  weapons 
system  as  a  low  cost  approach,  and  to  upgrade  reliability  of 
the  system  by  replacing  the  AN/UYK-7  central  computer  of  the 
AN/SPY-IA  system  by  distributed  computing  power.  Rapid 
repair  turnaround  and  low  component  replacement  cost  in  the 
system  in  case  of  failure,  and  graceful  degradation  of  the 
system  are  of  utmost  importance  especially  for  military 
applications . 

The  available  lab  system  at  NPS  is  made  up  of  single 
board  computers  building  MULTIBUS  clusters  which  are 
connected  via  an  Ethernet  Local  Area  Network. 

2 .  Systems  Architecture 

The  lab  system's  hardware  configuration  shown  in 
Figure  1.1  consists  of  two  clusters  with  up  to  four  Intel 
iSBC  86/12A  single  board  computers  (SBC)  in  a  cluster  at  the 
present   time.   A  MULTIBUS   serves   as  the   interconnection 
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Figure  1.1   Hardware  Configuration  of  RTC*. 
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medium  for  all  cluster  elements,  i.e.  besides  the  SBC's,  a 
hard  disk  drive,  two  extra  memory  boards,  and  an  interLAN 
NI3010  Ethernet  Communication  Controller  Board  (ECCB).  The 
ECCB  provides,  via  a  transceiver,  the  cluster's  connection 
to  the  Ethernet. 

With  the  MULTIBUS  as  an  intracluster  bus  and  the 
Ethernet  as  an  intercluster  bus  the  system's  configuration 
looks  similar  to  Carnegie  Mellon's  Cm'-^'  [Ref.  2].  Due  to  its 
goal  to  serve  time  critical  applications  in  a  real  time 
environment  the  AEGIS  lab  system  is  known  as  Real-Time 
Cluster  Star  (RTC-). 

The  system's  software  configuration  shown  in  Figure 
1.2  consists  of  a  MCORTEX  kernel  on  every  SBC,  MCORTEX 
global  data  on  one  extra  memory  board,  known  as  Common 
Memory,  and  Shared  Memory  on  the  second  extra  memory  board 
in  every  cluster.  Besides  the  MCORTEX  kernel,  also  the 
CP/M-86  operating  system  and  DDT-86  are  available  in  local 
RAM  of  every  SBC,  and  the  user  area  provides  space  for 
application  programs.  The  CP/M  Multiuser  area  is  kept  on  the 
Common  Memory  board,  while  Shared  Memory  houses  user  shared 
data  and  some  system's  shared  data. 

SBC  1  in  every  cluster  is  dedicated  to  a  systems 
program  known  as  the  system  device  handler  and  packet 
processor  (called  a  driver  in  the  following).  Part  of 
Shared  Memory  is  used  as  a  data  exchange  buffer  between  any 
SBC  in  the  cluster  and  the  driver  board,  SBC  1,  for  Ethernet 
transmission  requests.  Another  part  serves  as  data  exchange 
buffer  between  the  driver  board  and  the  ECCB  for  handing 
over  messages  which  are  to  be  transmitted  and  messages  which 
have  been  received. 

The  distributed  MCORTEX  kernels  provide  the 
multiprocessing  capability  of  the  system.  System  processes 
and  user  processes  share  the  CPU  of  a  respective  SBC.  David 
Brewer  gives  an  in  depth  discussion  of  the  interrelationship 
and  the  scheduling  of  processes. 
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Figure  1.2    Software  Configuration  of  RTC*. 
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The  process  synchronization  is  accomplished  using 
eventcounts  and  sequencers  as  developed  by  Reed  and  Kanodia 
[Ref.  3].  Eventcounts  synchronize  all  processes,  those 
running  on  the  same  board  as  well  as  those  running  on 
different  boards  in  the  same  cluster  as  well  as  those 
running  on  boards  in  different  clusters. 

It  is   important  to   recognize  that   eventcounts  are 
also  data,  even  though  a  special  kind  of  data. 
3 .   Specific 

A  typical  application  situation  for  systems  like 
RTC"  is  time  critical  gathering  of  data  by  real  time  sensors 
(e.g.  radar),  processing  these  data  in  the  context  of 
information  gathered  by  other  sensors,  and  executing 
specific  algorithms  in  order  to  produce  data  that  are 
consumed  by  effectors  (e.g.  missile  launchers). 

Under  the  realistic  assumption  that  sensors  and 
effectors  are  locally  distributed  and  that  sensor-effector 
coupling  or  grouping  must  be  kept  flexible  for  the  sake  of 
weapon  system  survivability,  it  is  obvious  that  the 
different  processing  modules  cannot  be  kept  together  close 
enough  in  order  to  use  shared  memory  in  the  conventional 
sense . 

B .   BACKGROUND 

A  series  of  theses  starting  with  one  by  W.J  Wasson,  June 

1980,  which  defined  the  detailed  design  of  MCORTEX  based  on 
MULTICS  and  the  use  of  eventcounts  [Ref.  4],  developed  a 
highly  modular  system,  hardwarewise  and  sof twarewise ,  using 
commercially  available  components,  that  guarantee  low  cost, 
availability,  and  reliability.  D.K.Rapantzikos ,  March  1981, 
provided  initial  implementation  [Ref.  5],  E.R.  Cox,  December 

1981,  refinement  [Ref.  6],  and  S.G.  Klinefelter,  June  1982, 
dynamical  interaction  with  the  operating  system  during 
execution  [Ref.  7]. 

W.R.    Rowe,    June   1984,   put   the   multiuser   CP/M-86 
operating   system  under   control  of   MCORTEX  [Ref.  8],    and 

15 


finally  D.J.  Brewer,  December  1984,  extended  MCORTEX  to  a 
multicluster  system  without  shared  memory,  using  Ethernet  as 
cluster  interface. 

The  system's  functioning  was  shown  for  the  extended 
MCORTEX  version  up  to  the  level  of  systemwide  process 
synchronization  using  distributed  eventcounts  in  a 
multicluster  environment.  Even  though  eventcounts  are  data 
also,  and  communicating  eventcounts  is  shared  data 
communication,  this  special  shared  data  communication  lacks 
the  ability  of  user  shared  data  distribution  over  the  total 
system. 

This  thesis  tackles  this  important  step. 

C.   STRUCTURE  OF  THE  THESIS 
The  goals  of  this  thesis  are: 

1.  To  extend  the  existing  MCORTEX  version,  that  provides 
process  synchronization  and  single  cluster 
inter-systemprocess  data  communication  using  an  intracluster 
shared  memory,  to  multicluster  general  inter-process  data 
communication  in  an  Ethernet  Local  Area  Network  environment. 

2.  To  develop  an  appropriate  model  for  intercluster 
shared  memory  to  be  used  in  the  system. 

3.  To  accomplish  the  extension  without  changing  the 
MCORTEX  kernel,  but  modifying  PL/I-86  modules  only. 

Chapter  I  discusses  the  objective  of  the  AEGIS  Modeling 
Group  at  the  Naval  Postgraduate  School,  gives  an 
introductory  system's  overview,  a  brief  development  history 
of  the  system,  and  outlines  the  goals  of  this  thesis. 

Chapter  II  discusses  three  different  approaches  studied 
in  developing  the  concept  of  intercluster  shared  memory  for 
RTC",  and  the  reasoning  that  lead  to  the  decision  for  the 
chosen  model. 

Chapter  III  presents  the  organization  of  intracluster 
shared  memory,  the  use  of  the  user  shared  data  area,  and  the 
intracluster  data  flow. 
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Chapter  IV  provides  an  in  depth  presentation  of  the 
development  and  realization  of  intercluster  data  sharing  in 
RTC* . 

Chapter  V  summarizes  the  current  state  of  the  system 
and  addresses  possible  future  enhancements. 
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II.  ORGANIZATION  OF  INTERCLUSTER  SHARED  MEMORY 

A.   SHARED  MEMORY  MODELS 

In  developing  the  concept   of  intercluster  shared  memory 
for  RTC*,  three  different  approaches  were  studied: 

1)  no  replication  of  intracluster  shared  memory, 

2)  total  replication  of  intracluster  shared  memory,  and 

3)  partial  replication  of  intracluster  shared  memory. 

The   logical  structures   of  these   approaches   are  shown   in 
Figure  2.1. 

1.   No  Replication 

This  model  views  the  intercluster  shared  memory  as 
the  sum  of  individual  intracluster  shared  memories  of  all 
clusters  available  in  the  system.  This  is  very  similar  to 
the  approach  chosen  for  Cm*. 

Every  shared  data  item  is  kept  only  once  in 
intercluster  shared  memory,  normally  in  the  intracluster 
shared  memory  of  the  home  cluster  of  the  producing  process. 
Consuming  processes  have  to  go  through  the  various  bus 
hierarchies  of  the  system  in  order  to  access  the  respective 
item  at  the  time  when  consumption  is  to  start.  Apparently 
this  is  a  very  time  consuming  effort  if  the  respective  data 
item  is  not  resident  close  to  the  consuming  process.  Close 
in  this  context  refers  to  being  located  in  shared  memory  of 
the  consuming  process'  home  cluster.  In  terms  of  time 
efficiency  for  this  model,  the  only  reasonable  solution  for 
this  situation  is  to  put  producing  and  consuming  processes 
as  close  together  as  possible  in  order  to  increase  the  rate 
of  cluster  local  hits. 

The  space-time  dilemma  becomes  obvious.  In  terms  of 
space,  this  approach  is  the  most  efficient  one,  because 
there  exist   no  duplications  of  any   data  item  in   the  whole 
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Figure  2.1   Intercluster  Shared  Memory  Models 
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system.  The  intercluster  shared  memory  space  is  equal  to  the 
sum  of  all  intracluster  shared  memory  spaces  in  the  system. 

However,  if  we  accept  the  fact  that  memory  becomes 
cheaper  and  cheaper  every  year  due  to  development  of 
technologies  that  put  more  and  more  memory  space  on  a  chip, 
then  we  could  afford  to  replicate  data  in  different  memories 
of  the  system  in  order  to  increase  the  number  of  cluster 
local  hits,  or  even  to  ensure  that  only  local  hits  happen  in 
the  system.  This  leads  to  the  second  model  of  intercluster 
shared  memory. 

2.   Total  Replication 

The  opposite  extreme  of  no  replication  is  total 
replication  of  all  shared  memory,  i.e.  every  intracluster 
shared  memory  keeps  all  shared  data  items  and  so 
intercluster  shared  memory  consists  of  as  many  copies  of 
intracluster  shared  memory  as  there  are  clusters  in  the 
system.  Due  to  the  necessity  that  all  intercluster  shared 
memory  has  to  fit  in  every  intracluster  shared  memory,  the 
available  space  for  intercluster  shared  memory  is  equal  to 
the  space  of  the  smallest  intracluster  shared  memory  of  any 
cluster  in  the  system.  Therefore  it  must  be  ensured  that  the 
smallest  intracluster  shared  memory  is  large  enough  to  keep 
all  shared  data  items  needed  in  the  system. 

This  model  makes  sure  that  only  cluster  local  hits 
occur  in  the  system,  and  that  every  consuming  process  finds 
every  data  item  in  shared  memory  of  its  home  cluster.  This 
seems  to  be  a  very  time  efficient  approach  that  suits  the 
demand  of  having  data  as  close  as  possible  to  the  producer 
and  the  consumer  as  well. 

A  major  problem  with  this  approach  however  is  the 
increased  overhead  in  maintaining  and  updating  of  shared 
data  items  that  are  never  used  at  a  certain  cluster.  This 
overhead  especially  consists  of  traffic  on  the  systems  buses 
and  processing  time  of  the  hosts  at  the  interfaces  between 
clusters   and  transmission  medium.    This  traffic   overhead 
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slows  down  the  data  distribution  so  that  it  takes  longer  for 
data  to  be  available  at  the  consuming  process'  cluster  for  a 
local  hit  there. 

The  compromise  is  a  combination   of  these  first  two 
models,  where  only  necessary  replication  of  data  is  done. 
3 .   Partial  Replication 

In  this  model  every  cluster  maintains  shared  data 
only  if  those  data  are  used  at  a  specific  cluster,  i.e. the 
producing  and  the  consuming  clusters  only  keep  a  copy  of 
respective  data  items,  no  superfluous  information  is 
maintained  and  there  is  no  superfluous  traffic  on  the 
transmission  medium  and  the  system  buses.  The  intercluster 
shared  memory  in  this  approach  is  equal  to  the  union  of  all 
individual  intracluster  shared  memories  in  the  system  and 
only  the  intersections  are  replicated.  There  can  be 
different  intersections  between  different  cluster  groups  in 
the  system.  This  approach  is  the  most  efficient  one  in 
terms  of  space  and  time.  The  traffic  on  the  transmission 
medium  and  the  system  buses,  and  the  amount  of  processing 
time  needed  for  data  exchange  is  kept  to  a  minimum.  Also,  as 
in  the  total  replication  approach,  only  cluster  local  hits 
will  occur. 

The  overall  policy  is  to  transmit  shared  data  to 
all  consuming  clusters  as  soon  as  possible  after  production, 
and  to  transmit  those  data  to  consuming  clusters  only. 

This  approach  seems  to  be  the  most  adequate  one  for 
a  distributed  real  time  system,  as  it  reflects  the  optimal 
compromise  in  terms  of  speed  , space,  and  update  overhead. 

Intercluster  shared  memory  by  partial  replication  of 
intracluster  shared  memories  was  therefore  chosen  for 
implementation  in  RTC'-^*. 
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III.  ORGANIZATION  OF  INTRACLUSTER  SHARED  MEMORY 

A.   CLASSES  OF  SHARED  DATA 

Looking  closer  at  shared  data,  we  realize  that  there  are 
different  classes  of  shared  data  used  in  the  system.  Some 
data  is  shared  among  processes  on  the  same  board  only,  some 
is  shared  among  processes  on  different  boards  in  the  same 
cluster,  and  some  is  shared  among  processes  in  different 
clusters . 

It  was  decided  to  keep  all  shared  data  on  special  memory 
boards,  even  though  some  of  the  data  is  produced  and 
consumed  on  the  same  board.  To  protect  system's  data  used  by 
the  operating  system,  these  data  items  are  stored  in  Common 
Memory,  which  is  beyond  the  reach  of  user  data  memory, 
called  Shared  Memory. 

All  MCORTEX  global  data  are  maintained  in  Common  Memory. 
Every  cluster  has  one  Common  Memory  where  all  MCORTEX  global 
data  needed  in  the  respective  cluster  is  kept.  Brewer 
describes  the  logical  organization  of  Common  Memories.  Due 
to  the  fact  that  eventcounts  are  used  for  intracluster  and 
intercluster  process  synchronization,  some  of  these 
eventcounts  are  replicated  in  more  than  one  cluster. 

It  must  be  recognized  that  there  exist  system's 
eventcounts  in  every  cluster,  e.g.  ERB_READ  and  ERB_WRITE. 
These  are  used  strictly  cluster  internally  and  do  not  belong 
to  the  intersection  of  intercluster  Common  Memory.  These 
system  event count  have  the  same  name  in  every  cluster,  but 
their  respective  values  are  never  distributed  over  the 
system.  Only  user  eventcounts  that  are  used  in  more  than  one 
cluster  are  distributed  and  therefore  replicated  in 
respective  clusters. 
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B.  SYSTEM  SHARED  DATA 

A  similar  situation  exists  in  Shared  Memory.  There  are 
three  data  items  in  Shared  Memory  which  are  used  exclusively 
within  the  cluster: 

1)  the  Ethernet_Request_Block, 

2)  the  Transmit_Data_Block,  and 

3)  the  Receive_Data_Block. 

These  are  data  items  shared  between  the  driver  residing 
on  SBC  1  and  either  MCORTEX  kernels  on  other  boards  or  the 
ECCB.  These  system's  data  items  are  needed  to  establish 
cluster  external  communication.  Information  needed  by  the 
driver  about  outgoing  and  incoming  messages  has  to  be 
communicated  via  Shared  Memory,  because  it  is  not  possible 
to  access  local  memory  of  any  SBC  from  outside  the  board. 

As  is  true  for  system  eventcounts  in  Common  Memory, 
these  three  system  shared  data  items  are  also  used  strictly 
cluster  internally  and  do  not  belong  to  the  intersection  of 
intercluster  Shared  Memory,  even  though  they  have  the  same 
names  in  every  cluster.  Only  user  shared  data,  that  are 
shared  in  more  than  one  cluster  are  distributed  and 
therefore  replicated  at  respective  clusters. 

As  described  by  Brewer,  the  Ethernet  Request  Block,  the 
Transmit  Data  Block,  and  the  Receive  Data  Block  reside  in 
this  order  in  the  lower  part  of  Shared  Memory  at  addresses 
lOOOOH,  10078H,  and  10666H  respectively.  The  User  Shared 
Data  Block  starts  at  address  10C58H  and  goes  up  to  17FFFH  as 
the  highest  address  in  Shared  Memory  in  the  present 
implementation  of  RTC*. 

C.  USER  SHARED  DATA 

Shared  data  items  are  basically  interfaces  between 
different  processes.  Processes  communicate  via  these  shared 
data.  It  is  therefore  important  to  agree  on  the  name,  size, 
and  structure  of  shared  data  used  by  different  programmers 
for   different  process   modules.     This   agreement  must   be 
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accepted  by  all  programmers  of  any  system  module  and  can  be 
thought  of  as  reached  under  the  guidance  of  a  lead 
programmer. 

An  individual  programmer  can  still  use  any  other  private 
name  and  structure  for  some  variable,    as  long  as  he  or  she 
ensures  that   communication  with   any  other  module  is   done 
using  the  agreed  upon  name  and  structure. 
1.   Organization  of  Shared  Data 

Shared  data  items  are  organized  as  circular  queues 
of  structures,  where  the  actual  item  is  a  structure  and  the 
queue  serves  as  buffer  between  producers  and  consumers.  This 
is  true  for  user  shared  data  and  system  shared  data  as  well. 

While  system  shared  data  items  have  fixed  predefined 
structures  and  queue  lengths ,  a  user  shared  data  item  can  be 
of  any  structure,  and  a  user  shared  data  queue  can  be  of  any 
length.  The  only  restriction  is  that  all  user  shared  data 
queues  needed  at  some  cluster  must  fit  together  into  the 
User  Shared  Data  Block  in  Shared  Memory  of  that  cluster. 

The  length  of  specific  data  queues  is  another 
important  issue  to  be  agreed  upon  by  all  programmers  using 
respective  shared  data  items.  The  chosen  queue  length 
depends  on  the  expected  average  input  and  output  rate  of  a 
specific  data  item  queue.  The  goal  is  to  reduce  or,  if 
possible,  to  avoid  idle  waiting  times  at  producing  processes 
due  to  a  filled  up  queue  caused  by  slow  consumption. 

As  mentioned  in  Chapter  II,  the  data  communicating 
version  of  RTC*^'  developed  in  this  thesis  will  use  the 
concept  of  partial  replication  of  Shared  Memory.  Therefore 
we  think  of  intercluster  Shared  Memory  as  the  union  of  all 
intracluster  shared  memory  blocks  that  contain  user  shared 
data.  Data  communication  is  only  possible  among  clusters 
that  actually  share  data  (i.e.  there  exist  an  intersection 
of  intracluster  Shared  Memories  of  those  clusters  and  the 
respective  shared  data  item  is  in  the  intersection) .  To  put 
it   another  way,    an   intersection  of  intracluster   Shared 
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Memories  is  only  needed  if  processes  in  respective  clusters 
need  to  communicate.  If  intracluster  Shared  Memories  only 
keep  those  shared  data  items  needed  (produced  or  consumed) 
by  some  process  in  the  cluster,  then  automatically  the 
minimum  intersection  and  therefore  the  least  duplicated  use 
of  memory  space  and  the  most  efficient  use  of  time  for 
maintaining  the  data  is  guaranteed. 
2.   Storage  of  User  Shared  Data 

In  order  to  further  accomplish  efficient  use  of 
memory  space,  the  system  is  set  up  in  such  a  way,  that  user 
shared  data  queues  can  be  stored  at  any  address  in  the  User 
Shared  Data  Block  in  Shared  Memory.  There  must,  however,  be 
enough  space  available  between  the  starting  address  of  the 
queue  and  the  highest  possible  physical  memory  address 
(i.e.l7FFFH  in  the  present  implementation). 

This  flexibility  also  allows  for  contiguous  storage 
of  all  user  shared  data  and  thus  the  available  storage  space 
is  most  efficiently  used. 

The  same  data  item  can  reside  under  different 
addresses  in  different  clusters.  The  application  programmers 
do  not  have  to  worry  about  the  addresses,  they  refer  to  a 
specific  data  item  by  its  name.  The  lead  programmer  will 
take  care  of  assigning  addresses  to  shared  data  queues.  When 
and  how  this  is  done  will  be  discussed  in  Chapter  IV.  For 
now  it  should  suffice  to  realize  that  the  organization  and 
storage  of  user  shared  data  in  this  implementation  is  done 
with  the  least  duplication  of  data  items,  where  each  shared 
data  is  available  in  the  local  cluster. 

D.   RELATION  BETWEEN  SHARED  DATA 

An  important  relation  exists  between  system  shared  data, 
eventcounts  and  user  shared  data,  which  is  exploited  by  the 
driver  for  its  data  communication  task. 

The  system  internal  management  of  a  data  queue  is 
controlled  using  an  eventcount  <dataname>_IN  and  an 
eventcount  <dataname>_OUT .     These  eventcounts   have  to   be 
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distributed  over  the  same  clusters  as  the  related  data  item, 
in  order  to  ensure  that  a  consumer  does  not  read  a  data  item 
before  it  is  in  the  queue,  and  a  producer  does  not  write  a 
new  item  into  an  already  used  slot  before  the  old  item  has 
been  consumed  by  all  its  consumers.  The  eventcount 
<dataname>_IN  tells  all  consumers  that  an  item  is  available, 
the  eventcount  <dataname>_OUT  tells  the  producer  that  a 
former  used  slot  is  available  for  new  data. 
1.   The  Ethernet  Request  Block 

Refer  to  Figure  3.1  for  the  following  discussion. 
The  system  shared  data  queue,  the  Ethernet  Request  Block 
(ERB)  is  filled  with  Ethernet  Request  Packets  (ERP) 
initiated  by  any  process  resident  at  the  cluster  when  it 
calls  for  an  update  of  the  value  of  an  eventcount  that  is 
also  needed  at  some  other  cluster. 

The  many  producers  of  Ethernet  Request  Packets  are 
kept  in  sequence  by  the  systems  sequencer  ERB_WRITE_REQUEST , 
which  basically  is  a  ticket  machine  that  makes  sure  that 
only  one  packet  at  a  time  is  put  into  the  Ethernet  Request 
Block,  and  that  Ethernet  Request  Packets  are  put  in  on  a 
first  come  first  serve  basis.  The  only  consumer  of  Ethernet 
Request  Packets  is  the  driver  on  SBC  1. 

An  Ethernet  Request  Packet  keeps  the  following 
information  in  its  eight  byte  structure: 

command  (i.e.  OOH  means  eventcount) 

type_name  (i.e.  8  bit  eventcount  id) 

name_value  (i.e.  16  bit  eventcount  value) 

remote_addr  (i.e.  16  bit  addr  of  external  cluster) 

System  eventcounts  ERB_WRITE  and  ERB_READ  play  the 
functional  roles  of  <dataname>_IN  and  <dataname>_OUT 
respectively  for  this  system  shared  data  queue. 

We  realize  that  ERPs  in  the  ERB  are  in  partial 
order.  The  order  of  packets  for  different  eventcounts 
<dataname>_IN  or  <dataname>_OUT  is  of  minor  importance.  More 
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Figure  3.1    The  Ethernet  Request  Block. 
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important  to   notice  is  that   the  logic  of   eventcounts,   if 
used  correctly,  ensures 

a)  that  a  packet  with  an  eventcount  <dataname>_OUT  always 
comes  after  a  packet  with  the  respective  eventcount 
<dataname>_IN,  and 

b)  that  all  packets  with  eventcounts  <dataname>_IN  for  a 
specific  data  queue  are  in  total  order,  which  is  also  true 
for  all  packets  with  eventcounts  <dataname>_OUT  for  a 
specific  data  queue. 

2.   User  Shared  Data  Block 

As  mentioned  above,  user  shared  data  queues  can  be 
of  any  length  and  the  data  items  can  be  of  any  structure, 
but  every  data  item  has  a  specific  structure  that  is 
replicated  in  every  slot  of  its  data  queue. 

Due  to  the  information  contained  in  the  eventcount 
value,  a  specific  slot  in  a  data  queue  has  to  be  written 
before  the  eventcount  is  advanced  and  also  the  eventcount 
has  to  have  been  advanced  before  the  next  slot  is  written 
to.  The  application  programmer  has  to  be  aware  of  this 
logical  sequence  when  using  eventcounts.  The  system  then 
ensures  that  always  the  next  higher  slot  in  the  queue  is 
written  to,  and  this  only  if  this  slot  is  available  for 
overwrite . 

This  scheme  also  ensures  that  the  data  items  in  a 
respective  queue  are  totally  ordered.  Furthermore,  it  is 
ensured  that  respective  Ethernet  Request  Packets  that  keep 
value  information  of  an  eventcount  related  to  this  data  item 
are  in  the  same  order  as  the  data  item  iterations  in  the 
data  queue.  This  is  also  true  if  an  eventcount  relates  to 
multiple  data. 

These  facts  about  the  relation  between  eventcounts, 
Ethernet  Request  Packets,  and  user  shared  data  is  the  basis 
for  the  logic  of  the  implementation  of  the  drivers  data 
transmission  and  data  reception  tasks. 
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Figure  3.2   User  Shared  Data  Queues. 
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E.   INTRACLUSTER  DATA  FLOW 

As  mentioned  earlier,  we  assume  to  have  the  classical 
producer- consumer  situation  for  all  user  shared  data  in  the 
system.  Data  items  are  kept  in  circular  data  queues  that 
serve  as  buffers  between  producers  and  consumers.  Due  to 
this  assumption,  all  user  shared  data  are  related  to  some 
eventcount,  which  replaces  the  semaphore  used  in  the 
classical  example.  Refer  to  Figure  3.3  for  the  following 
discussion. 

A  user  process  resides  in  the  user  area  of  local  RAM  on 
some  SBC.  The  process  becomes  active  when  the  scheduler 
chooses  it  as  the  next  process  to  run  after  it  was  ready. 
Before  a  producer  process  can  place  the  produced  data  item 
into  the  queue,  a  slot  must  be  available.  Slot  availability 
can  be  checked  by  comparing  the  <dataname>_IN  and  the 
<dataname>_OUT  eventcount  values  of  the  respective  data 
queue . 

A  consumer  process  becomes  ready  only  when  the  value  of 
the  respective  <dataname>_IN  eventcount  has  reached  the 
awaited  threshold,  indicating  that  there  is  a  new  iteration 
of  the  data  item  available  in  the  data  queue. 

A  process  which  consumes  data  and  produces  new  data  as 
well  obeys  the  same  rules.  It  is  of  utmost  importance  that 
the  application  programmers  use  eventcounts  and  the  AWAIT 
and  ADVANCE  primitives  correctly, 

A  producer  process  when  running  produces  shared  data 
items,  puts  these  items  into  user  shared  memory,  if  there  is 
space  in  the  queue,  and  then  calls  the  system  primitive 
ADVANCE  (EVC).  This  system  process  then  increments  the  value 
of  the  respective  eventcount  and  checks  if  this  eventcount 
is  distributed  and  therefore  a  cluster  external  copy  needs 
to  be  updated.  If  so,  it  calls  another  system  primitive, 
SYSTEM$IO,    which   in   turn   gets   a   ticket   from   the 
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ERB_WRITE_REQUEST  sequencer  and  puts  an  Ethernet  Request 
Packet  into  the  Ethernet  Request  Block  when  its  ticket 
number  becomes  the  lowest  in  the  waiting  line. 

If  no  remote  copy  is  needed,  then  no  Ethernet  Request 
Packet  is  produced,  because  all  consumers  reside  in  the  same 
cluster  as  the  producer,  and  the  cluster  internal 
synchronization  can  take  place,  as  all  needed  data  (i.e. 
event count  value  and  shared  data,  if  any)  is  present  at  the 
cluster.  A  waiting  consumer  process  becomes  ready  and  when 
activated  consumes  the  shared  data  item  from  Shared  Memory. 
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IV.  INTERCLUSTER  DATA  SHARING  IN  RTC- 

A.   INTERCLUSTER  CONNECTION 
1.   The  Ethernet 

As  mentioned  in  the  system  overview  in  Chapter  I, 
all  clusters  in  RTC*  are  connected  via  an  Ethernet  Local 
Area  Network.  A  detailed  specification  of  the  Ethernet  is 
given  by  Xerox  Corporation  [Ref.  9].  The  Ethernet  provides 
the  lowest  two  levels  in  the  International  Standards 
Organization's  Open  System  Interconnection  (ISO  OSI) 
reference  model,  i.e.  the  Physical  Layer  and  the  Data  Link 
Layer.  Higher  levels  are  collectively  seen  by  the  Ethernet 
as  the  Client  Layer.  The  RTC-'s  driver  provides  the 
system's  Client  Layer  and  the  home  board  of  the  driver,  SBC 
1,  serves  as  a  host  in  the  Ethernet's  communication  subnet. 
The  physical  connection  of  a  cluster  to  the  Ethernet's 
coaxial  cable  is  provided  via  the  ECCB  NI3010,  the  interface 
between  the  MULTIBUS  and  the  transceiver  which  actually  is 
the  tap  clamped  on  the  coaxial  cable. 

While  the  interface  board  provides  the  hardware 
connection  between  the  highest  level  system  bus  (Ethernet) 
and  the  cluster  bus  (MULTIBUS),  the  ECCB  software  and  the 
driver  are  responsible  for  correct  exchange  of  messages 
transmitted  or  received  by  any  cluster  in  RTC"=^'. 

As  is  true  for  all  SBCs ,  also  communication  with  the 
ECCB  NI3010  has  to  be  done  via  board  external  buffers.  In 
contrast  to  inter-SBC  communication,  which  is  synchronized 
by  eventcounts,  intercommunication  between  SBC  1,  the 
driver's  home  board,  and  the  ECCB  is  synchronized  using 
interrupts  (e.g.   Transmit_DMA_Done  or  Receive_DMA_Done ) . 

An  in  depth  description  of  the  hardware  NI3010  is 
given  by  InterLAN  Corporation  [Ref.  10].  The  software 
driver  was  developed  by  David  Brewer.  Brewer's  thesis 
provided   the   basic   scheme  for   intercluster   exchange   of 
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eventcount  values.    The  contribution  of   this  thesis   is  to 
enhance  the  basic  scheme  for  a   general  data  exchange  in  the 
system  by  modifying   the  driver  software  and   exploiting  the 
logical  interrelation  between  event counts  and  shared  data. 
2.   The  Ethernet  Packet 

Figure  4.1  shows  the  frame  format  of  an  Ethernet 
packet.  This  is  a  given  structure  produced  by  the  ECCB. 
Information  to  be  put  into  four  of  the  six  fields  have  to  be 
provided  by  the  client.  Preamble  and  Frame  Check  Sequence 
are  added  by  the  ECCB  for  receiver  synchronization  and  error 
checking  respectively. 

For  a  destination  address,  any  six  byte  combination 
except  all  zeroes  can  be  used,  which  is  also  true  for  the 
source  address.  The  arrows  on  the  right  hand  side  and  the 
bottom  of  Figure  4.1  indicate  the  serial  transmission 
sequence  of  the  bytes  and  bits.  The  very  first  bit 
transmitted  in  the  destination  field  indicates  whether  the 
destination  address  is  a  multicast  or  a  physical  address.  If 
this  bit  is  1,  making  the  first  byte  of  the  destination  an 
odd  number,  then  this  address  is  a  multicast  address  (group 
address  of  any  number  of  clusters).  A  special  multicast 
address,  all  ones,  is  reserved  as  the  so-called  broadcast 
address,  which  addresses  all  participants  in  the  network. 

If  the  first  bit  is  0  then  the  destination  is  a 
physical  address.  Physical  addresses  are  fixed  addresses  of 
ECCBs .  Xerox  Corporation  takes  care  that  physical  addresses 
are  unique,  i.e.  every  physical  address  is  used  only  once  in 
any  ECCB  worldwide. 

Due  to  the  just  described  restrictions,  there  are 
actually  2"'"'47  different  combinations  available  to  be  chosen 
as  non-physical,  non-broadcast  destination  addresses.  For 
the  present  implementation  of  RTC''^  it  was  decided  that  two 
bytes  are  more  than  adequate,  because  the  maximum  number  of 
stations  for  an  Ethernet  Local  Area  Network  is  restricted  to 
1024  by   the  Ethernet   specification.    Therefore   the  first 
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Figure  4.1    The  Ethernet  Packet. 
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four  bytes  of  the  destination  are  kept  fixed  03H,  OOH,  OOH, 
OOH  providing  the  multicast  indication  by  an  odd  first  byte. 
For  the  the  source  address,  the  ECCB  allows  two 
possible  ways.  Either  this  address  is  not  provided  by  the 
client,  in  this  case  the  ECCB  automatically  inserts  its 
physical  address,  or  the  client  fills  in  a  source  address. 
This  second  way  speeds  up  the  transmission  process  and  was 
therefore  chosen  for  RTC"^'.  The  first  four  bytes  are  kept 
fixed  03H,  OOH,  OOH,  OOH  as  in  the  destination  field.  Byte 
five  and  six  contain  the  cluster's  address.  This  is  not  the 
ECCB's  physical  address  as  mentioned  by  David  Brewer,  but 
rather  a  software  address  of  the  transmitting  cluster. 

The  two  bytes  of  the  type  field  are  reserved  for 
use  by  higher  levels.  Clients  can  use  this  field  in  order  to 
exchange  information  about  a  specific  format  used  in  the 
data  field.  The  present  implementation  of  RTC*  will  not  use 
the  type  field  and  therefore  sets  it  to  OOH,  OOH. 

The  data  field  provides  space  for  up  to  1500  bytes. 
It  is  required  that  the  minimum  length  of  the  data  field  be 
46  bytes  in  order  to  generate  the  minimum  total  length  of  a 
sufficiently  long  message.  This  minimum  message  size 
requirement  guarantees  that  in  any  Ethernet  collisions  are 
detected  by  the  sending  stations,  even  if  source  and 
destination  stations  are  maximum  distance  (2.5  km)  apart, 
and  the  net  performs  at  worst  case  propagation  speed 
tolerated  by  the  Ethernet  specification.  Collision  detection 
by  the  sending  station  is  important  for  correct  backoff  and 
retry  in  order  not  to  loose  messages  in  the  network.  The 
ECCB  takes  care  of  this  minimum  length  requirement  as  will 
be  seen  later.  Also  the  sending  ECCB  attaches  a  four  byte 
frame  check  sequence  at  the  end  of  every  Ethernet  packet  in 
order  to  provide  a  basis  for  error  checking  to  the  receiving 
ECCB. 
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B.   DRIVER  -  ECCB  MESSAGE  HANDOVER 

By  a  chosen  wiring  option,  it  is  not  possible  to  access 
(write  or  read)  onboard  memory  of  an  SBC  or  the  ECCB  from 
outside  the  board.  Therefore  a  buffer  for  message  handover 
is  needed  for  outgoing  messages  as  well  as  for  incoming 
ones.  These  buffers  are  set  up  in  Shared  Memory  as  systems 
shared  data  Transmit  Data  Block  and  Receive  Data  Block.  In 
contrast  to  other  shared  data  (e.g.  Ethernet  Request  Block 
or  user  shared  data),  the  Transmit  Data  Block  and  the 
Receive  Data  Block  are  single  slot  queues  that  meet  the 
structure  requirements  given  by  the  ECCB  specification 
described  in  the  Ethernet  Communication  Controller  User 
Manual . 

1.  Transmit  Data  Block 

The  Transmit  Data  block  is  a  structure  of  1514  bytes 
that  contains  all  information  required  to  be  submitted  by 
the  client  in  order  to  enable  the  ECCB  to  build  the  Ethernet 
packet  described  above.  Figure  4.2  shows  this  structure.  The 
destination  and  source  fields  are  filled  with  the  preset 
address  parts  as  well  as  the  dynamically  changing  two  high 
bytes  of  the  destination.  The  type  field  keeps  the  values 
OOH,  OOH,  and  the  actual  message  content  is  kept  in  the 
lower  part  of  the  1500  bytes  data  field. 

2 .  Receive  Data  Block 

The  Receive  Data  Block,  see  Figure  4.2,  is  similar 
to  the  Transmit  Data  Block  and  carries  all  information 
contained  in  an  incoming  message,  i.e.  destination,  source, 
type  and  data  field.  In  addition,  the  receiving  ECCB  hands 
over  status  information  related  to  the  message,  that  can  be 
used  by  the  client  in  order  to  determine  the  length  and  the 
error  status  of  the  received  packet.  These  additional  items 
of  information  are  kept  in  the  first  four  bytes  (1  byte 
frame  status,  1  null  byte,  2  bytes  frame  length)  and  the 
last  four  bytes  (frame  check  sequence)  of  the  Receive  Data 
Block,  making  the  Receive  Data  Block  1522  bytes  long. 
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The  present  implementation  of  RTC'-^  ignores  the 
frame  check  sequence  and  concerns  itself  only  with  the  data 
field. 

Even  though  the  length  of  the  data  field  in  the 
Ethernet  packet  is  determined  by  the  length  of  the  actual 
message,  both,  the  Transmit  Data  Block  and  the  Receive  Data 
Block  provide  space  for  maximum  length  messages  in  order  to 
be  prepared  for  any  legal  message  size. 

C.   MESSAGE  TRANSMISSION  AND  RECEPTION 

The  main  task  of  the  driver  on  SBC  1  is  to  build  a 
message  that  is  to  be  transmitted  over  the  Ethernet,  and  to 
process  a  message  that  was  received.  For  transmission,  the 
message  has  to  be  built  in  the  Transmit  Data  Block  in  Shared 
Memory  first,  and  then  the  ECCB  is  to  be  triggered  for 
transmission.  For  reception,  after  the  ECCB  signaled  that 
it  has  put  a  message  into  the  Receive  Data  Block  in  Shared 
Memory,  the  correct  data  queues  in  Shared  Memory  have  to  be 
found  and  the  data  items  have  to  be  put  into  the  correct 
slots  in  their  respective  data  queues. 

In  order  to  be  able  to  do  this  correctly,  every  driver 
maintains  a  table  in  its  local  RAM  which  contains  all  the 
information  needed  about  the  relationship  between 
eventcounts  and  shared  data  items. 

1.   The  Relation  Table 

We  assume  that  every  user  shared  data  item  used  in 
the  system  is  related  to  some  eventcount.  The  driver 
exploits  <dataname>_IN  eventcount,  because  this  is  the 
trigger  for  shared  data  transmission  when  put  into  an 
Ethernet  Request  Packet  by  the  SYSTEM$IO  process. 

Only  if  a  <dataname>_IN  eventcount  was  advanced,  was 
there  a  new  data  item  put  into  the  respective  data  queue.  An 
eventcount  can  also  serve  as  a  <dataname>_IN  indicator  for 
multiple  data  items  that  are  updated  at  the  same  time.  The 
important  property  is  that  for  every  shared  data  item  there 
exist  one  <dataname>_IN  eventcount,   which  is  advanced  after 
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the  data  item  is  available  in  its  corresponding  data  queue 
in  Shared  Memory.  Only  if  an  eventcount  is  distributed  over 
the  system,  and  therefore  a  cluster  external  copy  is  needed, 
is  there  an  Ethernet  Request  Packet  produced  and  put  into 
the  Ethernet  Request  Block.  Every  data  item  is  distributed 
over  the  same  clusters  as  the  eventcount  to  which  it  is 
related.  A  <dataname>_OUT  eventcount  only  informs  everybody 
in  the  system  that  a  slot  in  the  respective  data  queues 
becomes  available  for  overwriting  (an  important  item  of 
information  for  producer  processes),  and  so  these 
eventcounts,  if  distributed,  will  be  transmitted  alone,  with 
no  user  shared  data  in  the  same  Ethernet  message. 

This  logical  interrelation  between  eventcounts  and 
user  shared  data  is  kept  in  the  relation  table  shown  in 
Figure  4.3,  which  is  a  structure  of  100  entries  (the  present 
implementation  of  RTC~  allows  for  100  eventcounts  per 
cluster) ,  which  holds  the  eventcount_id  and  the  number  of 
related  data  items  on  level  two,  and  information  about  up  to 
10  data  items  for  every  eventcount  on  level  three.  Besides 
the  knowledge  about  how  many  data  items  belong  to  some 
eventcount,  the  driver  needs  to  know,  where  to  find  a  data 
item,  what  is  the  items  structure  size,  what  is  the  data 
queue  length,  what  is  the  next  slot  to  be  sent,  and  what  is 
the  next  slot  into  which  to  put  a  received  item. 

The  relation  table  is  built  by  the  driver  during 
system  initialization  by  the  procedure  make_table,  see 
Appendix  A.  This  procedure  reads  the  file  relation.dat, 
which  has  to  be  present  on  the  disk  that  keeps  the  cluster's 
software. 

The  driver  (see  Appendix  D)  is  a  general  system 
process  that  is  identical  at  every  cluster.  The  relation 
table  is  cluster  specific  and  keeps  cluster  specific 
information  only.  The  relation.dat  file  has  to  be  set  up  by 
the  lead  programmer,  who  decides  what  application  program  is 
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Figure  4.3    The  Relation  Table. 

to   be   run   at   what  cluster,    and   therefore   knows   what 
eventcounts  and  user  shared  data  are  needed  at  a  cluster. 

The  relation.dat  file  basically  is  a  table 
consisting  of  five  columns  as  shown  in  Table  I.  It  keeps 
eventcount  identification,  number  of  data  related  to  this 
eventcount,  and  for  every  data  item  the  address  of  the  first 
byte  in  its  data  queue,  the  length  of  the  data  queue  (//  of 
slots),  and  the  length  of  the  data  item  structureC//  of 
bytes).  The  last  line  in  the  relation.dat  file  serves  as  a 
sentinel  consisting  of  zeroes  in  all  five  columns.  The 
procedure  make_table  expects  the  formatted  indata  to  be  in 
columns  5,  15,  25,  35,  45  respectively.   This  information  is 
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read  into  the  relation  table  entries  evc_id,  numdat, 
pointer,  qlen,  and  bytes  respectively.  Next_in  and  next_out 
are  initially  0  and  therefore  do  not  have  to  be  read  in. 

The  information  kept  in  the  relation  table  suffices 
for  the  driver  to  do  its  job.  The  driver  does  not  need  to 
know  anything  about  the  logical  structures  or  names  of  data 
items.  It  treats  a  data  item  as  a  sequence  of  bytes,  and  is 
only  interested  in  finding  the  correct  sequence  of  bytes  for 
transmission,  or  the  correct  place  in  Shared  Memory  to  put 
the  bytes  after  reception.  Procedures  make_message  and 
process_packet  take  care  of  this. 
2.   Data  Format 

A  decision  that  had  to  be  made  was  in  what  manner 
the  data  field  of  an  Ethernet  Packet  should  be  used  in  order 
to  exchange  data  in  RTC*.  The  question  was  discussed  whether 
to  use  different  fixed  formats  for  different  situations  and 
using  the  type  field  for  identification  of  the  format  used 
in  the  data  field.  After  recognizing  the  logical 
interrelationship  between  event count  and  shared  data,  that 
carries  the  possibility  of  uniquely  identifying  a  group  of 
shared  data  by  its  common  eventcount,  it  was  decided  to  keep 
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the  data  format  as  flexible  as  possible. 

The  first  four  bytes  of  the  data  field  will  always 
keep  the  eventcount  information  followed  by  as  many  data 
items  as  are  related  to  this  eventcount.  The  maximum  length 
of  these  data  items  together  is  restricted  to  1496  bytes  in 
order  to  respect  the  1500  byte  limit  of  the  data  field  when 
the  4  byte  eventcount  information  is  included.  This  seems 
to  be  more  than  adequate  for  the  purpose  of  RTC-,  and  still 
leaves  the  possibility  to  transmit  all  data  items  as  long  as 
a  single  item  is  not  longer  than  1496  bytes,  by  logically 
grouping  data  items  under  eventcounts  respecting  this 
restriction. 

The  eventcount  is  the  identifying  part,  therefore 
only  one  eventcount  is  transmitted  in  any  Ethernet  packet. 

3 .  Message  Transmission 
Message  transmission  is  triggered  by  an  Ethernet  Request 
Packet  (ERP)  available  in  the  Ethernet  Request  Block  (ERB); 
more  precisely,  by  an  advanced  eventcount  ERB_WRITE 
indicating  that  there  is  an  ERP  in  the  ERB  which  has  not 
been  processed  yet.  The  driver  with  its  preference  for 
outbound  messages  will  start  a  transmit  job  as  soon  as 
possible.  In  the  initialization  part,  the  driver  already  has 
preset  the  first  four  bytes  of  the  destination  field  and  all 
six  bytes  of  the  source  field.  Refer  to  Figure  4.4  for  the 
following  discussion. 

Bytes  five  and  six  of  the  ERP  are  copied  into  the 
two  high  bytes  of  the  destination  field  of  the  Transmit  Data 
Block,  making  the  first  14  bytes  of  the  Transmit  Data  Block 
complete. 

Next  a  four  byte  overlay  is  put  over  the  ERP,  using 
a  based  variable  [Ref.  11],  after  which  the  procedure 
make_message  (see  Appendix  B)  is  called. 

This  procedure  first  checks  if  the  ERP  contains  an 
eventcount  (in  the  present  implementation  only  eventcount 
related   ERPs   are  processed).     If   byte   one  of   the   ERP 
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Figure  4.4   Message  Transmission. 
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contains  OOH,  indicating  EVC_TYPE  then  the  first  four  bytes 
of  the  ERP  are  copied  over  into  the  first  four  bytes  of  the 
data  field  of  the  Transmit  Data  Block. 

Next  a  relation  table  look  up  is  done  under  the 
respective  eventcount_id  and  the  number  of  related  data 
items  is  found.  If  the  eventcountid  is  not  in  the  table, 
then  there  are  no  related  data  and  the  message  is  done, 
otherwise  the  first  related  data  item  is  found,  an  overlay 
(1500  bytes  in  the  present  implementation)  is  aligned  with 
the  data  queue,  using  the  address  information  (pointer)  of 
the  data  item.  Now  the  slot  number  (next_out)  and  item 
size(bytes)  are  combined  to  an  offset  in  order  to  find  the 
first  byte  to  be  copied  over  into  the  Transmit  Data  Block  to 
follow  the  eventcount  information  in  the  data  field.  The 
data  item  size  (bytes)  contains  the  number  of  bytes  to  be 
copied  over. 

The  next_out  of  this  data  item  in  the  relation  table 
is  updated  to  the  next  slot  number,  and  the  loop  starts 
again  for  the  next  data  item  related  to  this  eventcount. 
Meanwhile  also  the  total  bytecount  for  bytes  put  into  the 
data  field  of  the  Transmit  Data  Block  is  carried  on.  After 
all  the  related  data  has  been  copied  over  into  the  Transmit 
Data  Block,  this  bytecount  information  is  added  to  14  (6 
bytes  destination,  6  bytes  source,  2  bytes  type)  and  the 
resulting  bytecount  is  used  as  a  parameter  in  the  procedure 
transmit_packet ,  which  signals  the  ECCB  that  a  message  is 
ready  to  go  and  should  be  sent. 

Just  before  calling  procedure  transmit_packet ,  the 
driver  calls  ADVANCE  (ERB_READ) ,  which  makes  the  just 
processed  ERP  slot  available  for  reuse. 

The  ECCB  copies  the  number  of  bytes  signaled 
(minimum  60)  into  its  transmit  queue  and  puts  the  message 
out  over  the  Ethernet.  If  necessary  due  to  collisions,  the 
transmission  is  repeated  and  only  after  the  message  was 
successfully  sent  does  the  transmitter   become  ready  for  the 
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next  transmission,   which   is  prepared  by  the   driver  in  the 
above  described  fashion. 

4.  Message  Reception 
Message  reception  is  triggered  by  an  ECCB  interrupt 
signaling  that  there  is  a  received  message  available  in  the 
ECCB's  receive  queue.  Refer  to  Figure  4.5.  The  driver  then 
initializes  a  DMA  and  the  ECCB  puts  the  message  into  the 
Receive  Data  Block  in  Shared  Memory.  After  the  message  is  in 
the  Receive  Data  Block,  the  procedure  process_packet  (see 
Appendix  C) ,  is  called.  This  procedure  works  similarly  to 
the  procedure  make_message . 

Instead  of  getting  the  needed  information  from  an 
ERP,  procedure  process_packet  has  to  look  up  the  first  bytes 
in  the  data  field  of  the  received  message.  This 
implementation  of  RTC-  neither  uses  the  frame  status  and 
frame  length  information,  nor  the  frame  check  sequence. 

First  the  procedure  process_packet  looks  up  byte  one 
of  the  data  field  in  order  to  check  if  the  just  received 
message  contains  eventcount  information.  If  so,  it  finds  out 
if  the  value  of  the  just  received  eventcount  is  higher  than 
the  local  value  of  the  respective  eventcount,  because  the 
message  is  of  interest  for  this  cluster  only  if  the  remote 
eventcount  value  is  more  advanced  than  the  local  one. 

If  the  remote  value  is  higher,  a  relation  table  look 
up  is  made  under  the  eventcount_id  found  in  byte  two  of  the 
data  field. 

If  there  is  no  entry  in  the  relation  table  for  this 
eventcount,  then  no  related  data  exists  and  the  only  thing 
to  do  is  to  update  the  local  eventcount  value. 

If  an  entry  exists,  then  the  address  (pointer)  of 
the  first  related  data  item  is  found,  an  overlay  is  aligned 
with  the  respective  data  queue,  and  the  slot  number 
(next_in)  and  the  item  size  (bytes)  are  combined  to  an 
offset  in  order  to  find  the  first  byte  in  the  data  queue 
that  is  to  be  changed.  Then  the  number  of  bytes  found  in  the 
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Figure  4.5    Message  Reception. 
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item  size  information  is  copied  over  into  the  data  queue, 
starting  with  byte  five  of  the  Receive  Data  Block's  data 
field  (i.e.  the  first  byte  of  the  first  related  data  item 
received) . 

During  this  operation  also  the  bytecount  is  updated 
in  order  to  find  the  starting  byte  for  the  next  related  data 
item. 

Similar  to  the  procedure  make_message ,  the  procedure 
process_packet  updates  the  next_in  information  to  the  next 
slot  number  in  order  to  be  ready  for  the  next  incoming 
message  bringing  an  update  for  this  data  item  if  any. 

After  the  first  shared  data  item  is  copied  into  its 
correct  slot  in  Shared  Memory,  the  next  related  item  is 
copied  into  its  respective  queue.  After  all  received  related 
data  items  of  the  received  event count  are  updated,  the 
eventcount  is  advanced  to  its  new  value,  signaling  the 
shared  data  status  to  respective  consumers  at  this  cluster. 
The  procedure  process_packet  takes  care  of  advancing  the 
eventcount  only  after  all  related  shared  data  items  are 
updated,  guaranteeing  the  consistency  of  eventcount  values 
and  data  items. 

D.   DATA  SHARING 

It  is  obvious  that  data  sharing  using  buffers  in  Shared 
Memory  can  only  be  achieved  when  producers  and  consumers 
agree  upon,  where  to  put  and  to  find  the  respective  data 
items.  Also,  this  only  works,  if  producer  and  consumer  deal 
with  the  same  item  structure. 

In  a  system  like  RTC*^',  where  probably  many  applications 
programmers  write  different  system  modules ,  these 
programmers  have  to  agree  upon  the  shared  data  names  and  the 
structures  and  queue  lengths  (at  least  for  intracluster 
sharing) . 

Even  though  it  would  suffice  to  only  declare  those 
shared  data  items  that  are  actually  used  in  some  process, 
the   policy  followed   in  the   demonstration  program  was   to 
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include  a  common  declaration  file  in  every  module  in  order 
to  ensure  that  sharing  modules  really  work  with  the  same 
data  item.  Following  this  example  in  a  real  program  makes  it 
easier  to  maintain  all  shared  data  declarations,  probably 
done  by  the  lead  programmer. 

Applications  programmers  include  the  shared  data  file 
in  their  programs  and  only  have  to  be  concerned  about  the 
correct  use  of  those  items  actually  used  in  their  programs. 
Table  II  shows  the  file  share. del  for  the  demonstration 
program. 


TABLE  II 
FILE  SHARE. DCL 

DECLARE 

(de_ptr , tr_ptr ,mo_ptr)  pointer, 

1  deltaC0:19)  basedfdeptr) , 
2  dx  fixed  bin  il 
2  dy  fixed  bin  ll 
2   dz  fixed  bin  (7 

1  track(0:49)  based(tr_ptr) , 
2  x  fixed  Din  (15 
2  y  fixed  bin  (15 
2  z  fixed  bin  (15 

1  missile  order(0:49)  based(mo_ptr) , 
2  launcher  fixed  bin  (7), 
2  azimuth  float  binary, 
2  elevation  float  binary; 


This  file   ensures  unique  declarations   for  all   user  shared 
data  in  the  whole  system. 

Every  user  shared  data  item  is  declared  as  a  queue  that 
is  based  on  a  respective  pointer.  Using  based  variables 
provides  the  possibility  that  in  spite  of  total  user  shared 
data  declaration,  only  for  those  items  that  are  to  be 
resident  in  some  cluster's  Shared  Memory  physical  memory 
space  is   assigned.   This  leads   to  efficient  use   of  memory 
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space.    As   mentioned  before,    contiguous  storage   of  data 
queues  enhances  the  efficiency  even  more. 

This  requires  thoughtful  assignment  of  addresses  to  the 
different  data  queues  in  the  system.  As  for  the  relation.dat 
file  and  share. del  file,  the  custodian  for  the  assignment  of 
pointers  also  should  be  the  lead  programmer.  Applications 
programmers  do  not  have  to  worry  about  this  because  they 
refer  to  a  data  item  by  dataname.  Pointer  assignments  are 
kept  in  the  file  pointer. ass,  which  is  cluster  specific;  the 
share, del  file  is  the  same  for  every  cluster  in  the  system. 
Table  III  shows  the  two  pointer. ass  files  used  in  the 
demonstration  program. 


TABLE  III 
FILE  POINTER. ASS 


this  file  keeps  the  pointer  assignments 
for  shared  variables  used  at  cluster  1 

-I 
unspec(tr_ptr)= '8c58 'b4; 
unspec(mo_ptr)= ' 8d84 'b4; 

this  file  keeps  the  pointer  assignments 

for  shared  variables  used  at  cluster  2 

-kj 

unspec(tr_ptr)= ' 8c58 'b4; 
unspeci de_ptr)= ' 8d84 ' b4 ; 
unspec(mo_ptr)= ' 8dcd ' b4; 


In  order  for  processes  to  be  able  to  really  share  data 
in  Shared  Memory,  it  is  important  that  they  find  shared  data 
under  the  same  physical  address.  Under  INTEL'S  policy  that 
calculates  a  20  bit  physical  address  from  a  segment  and  an 
offset,  this  implies  that  user  shared  data  has  to  be  found 
in  the  same  segment,  the  pointer  or  logical  address  then  is 
the  offset  in  this  segment. 
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In  RTC'^'  this  is  realized  in  using  800H  as  a  data  segment 
register  value  and  using  sixteen  bit  pointers  for  shared 
data  starting  at  8000H.  The  lowest  Shared  Memory  address 
therefore  is  SOOH-IOH+SOOOH,  which  is  equal  to  8000H+8000H, 
or  lOOOOH.  The  lowest  byte  of  the  Ethernet  Request  Block 
resides  at  the  above  address. 

The  segment  used  by  a  process  is  defined  in  procedure 
create_proc.  It  is  important  that  the  parameters  4,  7,  and 
8,  i.e.  stack  segment  (SS),  data  segment  (DS),  and  extra 
segment  (ES)  in  the  create_proc  call  are  set  to  800H  when 
creating  a  process.  As  mentioned  by  Brewer  ,when  he 
describes  user  process  creation  [Ref.  1:  p.  49],  some 
PL/I-86  routines  assume  identical  contents  in  the  SS,  DS , 
and  ES  registers. 
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V.  CONCLUSION 

The  goals  of  this  thesis  were  achieved.  The  MCORTEX  real 
time  executive  is  extended  to  handle  multicluster  general 
inter-process  data  communication.  An  appropriate  model  for 
intercluster  shared  memory  is  implemented  by  partial 
replication  of  intracluster  shared  memory.  Only  PL/I-86 
modules  were  modified  or  newly  added. 

The  message  exchange  scheme  is  kept  as  flexible  as 
possible,  with  the  only  restriction  that  the  four  bytes  of 
eventcount  information  have  to  be  put  into  the  first  four 
bytes  of  the  data  field  of  the  Transmit  Data  Block,  and  all 
related  data  items  have  to  follow  in  the  sequence  given  by 
the  relation  table.  The  driver  takes  care  of  this. 

Maximum  data  length  in  a  single  message  is  restricted  to 
1500  bytes  in  accordance  with  the  Ethernet  specification. 
This  size  seems  more  than  adequate  for  the  purpose  of  RTC". 
If  longer  messages  are  needed  in  the  system,  a  correct  data 
exchange  can  be  achieved  by  breaking  up  the  message  into 
smaller  ones  relating  these  to  specific  eventcounts. 

The  driver  takes  care  of  correct  message  assembling  and 
processing,  and  is  --  as  a  special  systems  module  with  a 
dedicated  board  --  completely  transparent  to  the 
applications  programmer  and  user.  The  lead  programmer  will 
have  to  decide  how  to  distribute  different  applications 
modules,  and  where  to  store  data  queues  in  Shared  Memory.  He 
or  she  will  have  to  maintain  the  relation.dat  file  and  the 
pointer. ass  file,  and  also  the  agreed  upon  user  shared  data 
in  the  share. del  file. 

In  the  current  implementation  of  RTC-  the  distributivity 
of  the  eventcounts  (and  with  these  the  distributivity  of 
data  items)  have  to  be  set  at  system  initialization.  This 
restricts  the  dynamic  reconfiguration  of  the  system  after 
initialization.  Future  implementations  should  try  to  resolve 
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this  restriction.  A  possible  way  might  be  to  exploit  the 
general  broadcast  situation  of  an  Ethernet  environment.  As 
only  one  message  can  be  on  the  Ethernet  at  a  time,  and  as 
all  stations  on  the  net  have  to  listen  and  cannot  do 
anything  else  during  this  time,  this  situation  could  be 
exploited  in  the  following  manner. 

Use  the  eventcount_id  as  a  kind  of  multicast  address.  As 
there  is  only  one  eventcount  in  any  one  message  this  is  a 
unique  identification  of  what  information  is  carried  in  the 
message.  Every  cluster  "knows"  what  information  is  needed  at 
that  cluster.  If  the  eventcount_ids  of  related  data  items 
needed  at  some  cluster  are  put  into  the  group  address  table 
of  that  cluster's  ECCB,  then  every  Ethernet  packet  that 
carries  information  of  interest  for  this  cluster  will  be 
taken  in  and  processed. 

It  is  not  necessary  to  keep  the  remote  address  for  an 
eventcount  in  Common  Memory.  The  information  that  an 
eventcount  is  distributed  or  not  distributed,  meaning  a 
cluster  external  copy  is  needed  or  not  needed,  suffices. 
This  distributivity  information  can  be  initialized  for  the 
initial  system  constellation.  On  reconfiguration,  it  could 
then  be  automatically  and  dynamically  changed  without  having 
to  shut  down  and  reinitialize  the  whole  system. 

After  reconfiguration,  only  those  clusters  where  actual 
changes  were  made  broadcast  the  event count_ids  of  interest 
to  the  cluster.  Every  other  cluster  updates  its 
distributivity  information  for  those  eventcounts. 

There  was  not  enough  time  for  the  above  described 
implementation  in  this  thesis,  but  future  work  in  this 
direction  is  highly  recommended  in  order  to  make  the  total 
system  more  efficient,  more  robust,  more  survivable,  and 
more  flexible,  requirements  that  are  of  utmost  importance 
especially  for  military  applications. 
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APPENDIX  A 
PROCEDURE  MAKE_TABLE 

Procedure  make_table  is  the  first  procedure  called  by 
the  driver.  It  sets  up  the  relation  table  in  local  RAM  of 
SBC  1  by  reading  the  information  from  the  file, 
relation. dat . 

The  relation  table  is  a  three  level  structure  that  keeps 
the  eventcount_id  (evc_id)  and  the  number  of  data  items 
(numdat)  related  to  this  eventcount  on  level  two  and  the 
data  queue  address  (point),  number  of  slots  in  dataqueue 
(qlen) ,  number  of  bytes  in  item  structure  (bytes),  next  slot 
to  be  sent  (next_out ) ,and  next  slot  to  be  received  (next_in) 
on  level  three. 

There  are  maximum  100  level  one  entries  in  the  relation 
table,  because  the  maximum  number  of  eventcounts  at  any 
cluster  in  the  present  implementation  is  100.  For  every 
eventcount  a  maximum  of  10  related  data  items  are  possible. 
The  driver  looks  up  an  eventcount_id  and  finds  all 
information  necessary  to  either  combine  data  items  in  the 
Transmit  Data  Block  for  transmission,  or  put  received  data 
items  in  their  respective  Shared  Memory  slots. 

Procedure  make_table  expects  the  indata  evc_id  at  column 
5,  numdat  at  column  15,  point  at  column  25,  qlen  at  column 
35,  and  bytes  at  column  45  in  the  relation.dat  file. 
Next-out  and  next_in  are  initially  0  and  do  not  have  to  be 
read. 
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««*  ^;  *«  3)e  ##*#:<:  sje  jjj  ;jr  ,;«:,;£  Jit  ^c  sit  :}t  sie  ^^  ;'^  jjt  :^  >;t  :<«;;«  sjt ,;;-;{ :^  y^  :}c  ■/;  :(t  j)c  y^  «  3>t  V 

Jit  s^c  j^t  s^s  :{e  xe  x«  *  sit  ^  3!«  s{«  *  3p  >}c  jj:  #  xt «  *  *  *  j:t  »:< «  « s;«  5;c  :<t  J}: );:  j;c  j;c  jle  V ;;« *  Xt  y^  >;£  j;£  j'^  y^  >>:  jjt  3^ 

***   PROCEDURE  MAKE  TABLE       R.Hae^er,  Dec  1985      -'^^ 

JU  «v  «v  "^ 

'r'i«>^  —  — _  — .»_.^_.._  — _— ___^ — ^_-^___-_____ ,'jc^i^z 

***  This  procedure  reads  relation  values  from  file       ^'^'^ 
***  RELATION.DAT  into  the  relation  table.  ^^^ 

*  sic  j{e  *«  :{c  }!«  sli  ^  :;c  3{e :;;»  s;:  *>;«  :;e  Jli  *  j;«  jjc  ;^  ;;« Jlj  »:<  ;;t  >!c  ;;;  j;t  ,)e :;:  31:  jIt  ,!:«-«>!::;->:;  :^  >!«  y^  ^^ 

make_tahle:  procedure  ; 

declare 

relation  file, 

(.i,i)  fixed  bin  (15), 

eof  hit(e) ; 

open  file  (relation)  stream  input; 
i=0; 

eof='0'b4; 

do  while  ^eof=''?'b4)  ; 
i=i+i; 

/"  read  data  from  relation.dat  file  -/ 
set  file  (relation)  edit (rel_tab( i  )  .evc_id , 

rel_tab^  i ) .numdat ) 
(column  '5)  ,b4.(2)  ,column  '  15  ) ,  f  (2  )  )  ; 

do  j=l  to  ( rel_tab(i ) .numdat ) ; 

/*  read  data  for  all  related  items  */ 
set  file  ^relation)  edit 

(unspec  (  rel_tab  (  i  )  .da  ta  ;  ,1 )  .Doin  t  )  , 
rel_tab( i ) .la  ta ' j ) ,a len , 
rel_tab(i).data(j). bytes) 
(column  (25)  ,b4(4:)  ,  column  (35)  ,f '4)  .column  (45)  ,f  (4  )  ; 

maxq  byte5=max (maxa bytes, 
rel_tab(i )  .data(  .1)  .byte5'i'rel_  tah(  i  )  .data(  J )  .al°n) ; 

end; 

/*  if  sentinel  is  reached  */ 
if  rel_tab(i ) .evc_id  =  'e0'b4  then 
do; 

eof  =  'l  'b4; 

put  skiD  lis t(  'longest  data  aueue  at  this  cTister:'. 
maxabytes ,  '  bytes  '  ■  ; 
end; 
end; 
end  make  table; 


s^  sje  3ie  »;«  5{s  >;e  s;«  >):*#  sic  >;t:5s  s;t  3}e  sjt  j;e  sic  X:  :«!>;«#*  Xt  :<t :{«  5?  **«>:««  >«C5;s  s?  3;«  *«  >;t  >;:  J*  s^  Jis  #  Xt  *«  sis  s;j  >;«*  ^ 
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APPENDIX  B 
PROCEDURE  MAKE_MESSAGE 

Procedure  make_message  is  called  by  the  driver  when 
there  is  an  Ethernet  Request  Packet  in  the  Ethernet  Request 
Block  that  has  not  been  processed  yet. 

It  checks  the  ERP  for  eventcount  type,  and  if  the  ERP 
contains  eventcount  information,  it  sets  up  the  data  field 
of  the  Transmit  Data  Block.  The  eventcount  information  is 
always  put  into  the  first  four  bytes  of  the  data  field, 
followed  by  all  data  items  related  to  this  eventcount  in  the 
sequence  given  by  the  order  of  these  data  items  in  the 
relation  table. 

Procedure  make_message  also  keeps  track  of  the  bytecount 
of  the  total  message,  an  information  needed  by  the  ECCB  for 
transmission. 
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**«  :{s  sic  sj!  >;:  3;c  5{c  j;c «  :Jc  :<«»:»  ^  ^  5je  j}e  s^j  5j£  :<c  #;;:  s;c «« :<c  Xt -t «  ^  jje  jj:  :{c  Xt  >;e  «  j;;  5?  <t  :«c  j^t  3{t  >;£  «t «  ^ 

***       PROCEDURE  MAKE_^ESSAGE    R.  Haeeer,   Dpc  19  =  5  '-'-^'^ 

***  This  Drocedure  builds  the  Transmit  Data  Block  for    -*''' 
=!•**  a  message  to  be  transmitted  over  the  Ethernet.       •'"* 

sit  :;c  #  :J:  5jt  s;t -;  #  3X  #  *  >?  3je  >;;  ^  s;:  :;e  >;t  3{e  :<«  sit  sit  j;£  >;c  j;s  :{£  :{£  jjc  3je  ^  ^Ot  V  «  2?  Jf:  5?  *  3P  i;t  >;:  :«t  s}c  jjt  >^  ^  Ji^ 

make_messaffe :  procedure  J 

declare 

iat_pt r  pointer  , 

dat_vect(1500)  bit  (8)  based  (dat_?tr), 

(next_out , r  ,  j )  fixed  bin  (7), 

^off  .start  .last  ,1^)  fixed  bin  (15); 

/'^   check:  for  eve  */ 
if  erp_vecta)  =  EVC_TYPE  then 
do; 

bytecount=4; 
do  k:=l  to  4; 

/*  put  eve  info  into  data  field  =^/ 
tra!ismit_data_block.data(k)=erp_vect  (k) ; 
end; 


/"^   check  mes5ag;e 
put  skip  listv':: 


:'.transmit_data_block.data(lj,' 
transmit _data_blcck. data [2)  ,  ' 
transmit _data_block. data (3),' 
transmit  data  block.data^4),' 


r=i; 

/*•"  find  respective  relation  table  entry  */ 
do  while  (  (  rel_tab  \  r  ) .  evc_id  ''=  ero  vect(2))  S. 
(rel_tab(r  )  .evc_id  '^=  '?2^b4)); 

r=r+i; 
end; 


/*  i 

if  re 
do; 
/^ 

do  .1 
sta 
las 
byt 
dat 
nex 
/* 
off 


f  eve  entry  */ 
1  tab ( r ) .eve  id 


■=  '0^'b4  then 


put 
is 


for  every  related  item  "^Z 

=1  to  rel_tab( r ) .numdat ; 

rt  =  bytecount  +  i;        /'■' 

t  =  rel  tab(r).data(j)  .bytes; 

ecount=bytecount    +   last;    /* 

_ptr=rel_tab( r  )  .data ( j ) .poir 1 1  /*ali?n  datvect 

t_out  =  rpl_tab(r).data(.1).next_out; 

comput'^  offset  of  item  in  data  nueue  '^ / 
=  (rel  tab(  r  )  .data  ;  .1)  .bytes  "  next  out)  +  l; 


find  where  to 
/*  how  lon^  it 
keep  track  */ 
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/*  compute  next  slot  number  to  ^c  */ 
rel_tab(  r  )  .data(  ,1 )  .next_out=mod  (next_out  +  1, 

rel_tab(r) .data { j ) .alen ) ; 
do  k=0  to  (last-l ); 

/*  put  item's  bytes  into  data  field  '*'/ 
transmit_iata_block.data(k-^start  )=dat^vect  (k+of f ) ; 
end ; 
end; 
end; 

/*  compute  total  bytecount  for  message  */ 
bytecount=bytecount  +  14; 
end; 

else  do;    /*  if  not  eve  */ 
end; 
end  make  messa,9;e; 


*(•  SJ*  •!(*  5JC  5f«  •y*  5JC  3|C  3|C  3|C  «|«  *(»  JJ*  5J?  5^  3yC  ^|«  ^C  3(«  «y«  ^C  «f«  S^C  *,^  «f«  3|«  3J«  3^  S^  3^  3QC  3^  5p  3p  *f»  »|»  JjC  ^j*  3^»  3^  ^C  ^JC  3|C  9JC  SJC  #|«  S^  a^  3JC  «y«  5|-»  3J*  ^JC  3^*  3JC  #y^  *(*  4^  SJC  3JC 
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APPENDIX  C 
PROCEDURE  PROCESS_PACKET 

Procedure  process_packet  is  called  by  the  driver  when 
there  is  a  newly  received  message  in  the  Receive  Data  Block. 

It  checks  the  received  data  for  eventcount  type,  and  if 
the  message  contains  eventcount  information,  it  checks  if 
the  received  remote  eventcount  value  is  higher  than  the 
local  value  of  the  respective  eventcount.  Only  if  the  remote 
value  is  higher  than  the  local  value,  it  processes  the 
received  message.  Using  the  eventcount_id  in  byte  two  of  the 
data  field,  a  relation  table  look  up  is  done  and  all 
received  data  items  are  put  into  their  correct  slots  in 
Shared  Memory. 

After  all  data  items  are  placed  correctly,  the  local 
copy  of  the  respective  eventcount  is  updated  by  calling 
ADVANCE (EVC) . 
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jjc  sj:  sje  ^  5{c »;« X«  *#  >}5  *'{«********  9r  5;«  »!«*  Sit  *****  5>:  sje  *  sje  *#*  5{e ;}:  s;:  s)c  s;«  sj«  sj: »;« sj5  j(t  #  sje  3^  s;s  >js  :je  :;c  j;^ 

****  sf: :<« :J:si«>;csf:ji:s;es;s:;{:<ss^s;t>;j>;t:4s*:4e^>(;si:*^^##s!c^#:{e5j:**********:i}t ***>>:*>;«**:;<** ^*!;c 

***     PROCEDURE  ?RCCESS_PACKET     R.Haeeer,  Dec  1985   -'i** 

***  This  nrocedure  processes  received  messages.  *** 

'■''**  It  tak:es  the  data  from  the  Receive  Data  Block  and  ^«*- 

***  put  every  item  in  its  correct  slot  in  Shared  Memory.  ^'^'^ 

*'''*  It  also  calls  for  an  update  of  the  evencount  value.  *** 

«*«  '^^  V*  ^^  «''  V'  «^  "J^  *^  **^  *^   "^'^  *^  «^  '^  ^''  ^Jl*  *>*'  n'*  «^  ^^  ^^  *''  V'  *-*'  •J^  *V  *-^  ^»  «A»  "J'  «A#  %l«  *V  aJU  «^  ^^  «'#  •k««  O*  •>#  «'«  aA*  <^#  «(#  «'«  *J«  *0  0«  **f   <J^  a/^  <ky  «>^  «A*  «l«  <k*«  V«  ^'^  aA* 
^«  »,•  ^^  »(^  ^>  J|*  *^  ^|v  •j*  ^|v  ^(^  *!"»  »j»  • ,»  *|*  f^  ^1^  •(»  *,>»  ^^  ^W  V|«  ^f«  fi^  t ,«  ^^  *|fc  »fk  ^*  «f«  *,«  «|«  *f*  *,*  <^  *(■•  ^b  Vf^  *■,»  ^■^  •!«  *■,«  *\^  *|^  *|*  »,■*  ^i*  ^r*  t^  *l  M^  *l  1^  'i^  'C  'I*  ^(*  *^  *^  *(* 

process_packet :  procedure? 

DECLARE 

evcid  hit  (3 ) , 
local_evc_value  hit  (16), 
(dat_Dtr,p)  pointer, 
remote_evc_value  hit  (15)  hased  (p), 
dat_vect(150?^)  hit  ^8)  hased  (dat_-Dtr), 
(off .start , last ,k)  fixed  hin  (15), 
(next_in,  r,.i )  fixed  hin  (7); 
put  skiD  lis t ( 'recei vi nff' ) ; 

/*  check  for  eve  */ 
if  receive_data_hlock. data( 1 )=evc_type  then 
do; 

p  =  addr ( recei ve_data_block.data (3) ) ; 
evcid=receive_dat a  hlock.dat a (2 ) ; 
local_evc_value  =  read(evcid); 
if  local_evr_value  <  remote_evc_value  then 
do; 
r=i; 

/='■"  find  eve  entry  in  relation  table  */ 
do  while  (  (rel_tah  (r )  .evc_id  ""=  evcid)  S, 
(rel_tah  (r)  .evc_id  '^=  '00'h4)); 
r=r+i; 
end ; 

if  rel_tat  (r  )  .evc_id  '^=  '00 'h4  then 
do; 

hytecount=4;  /"^    jump  over  eve  info  */ 

do  .1=1  to  rel_ta  b(r  )  .numdat ; 

start=hytecount+i;  /*  compute  start  of  item  */ 
last=rel_tab(r ) .data(j ) .bytes;  /*  and  length  */ 
bytecount  =  bytecount  +  last ;  /=««  and  item's  end  */ 
next_i n= re l_tah(r). data (j). next  in; 

/*  comDute  offset  in  data  aueue  */ 
off=(la5t*next_in)  +  i; 

/*  compute  next  slot  number  to  fill  */ 
rel_tah(r).data(j) .next_in=mod (next_in+l , 

rel_tab(r).data(J).alen); 
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dat_ptr=rel_tab(  r  )  .data  (j  )  .point ;  /=*  align  datvect=^/ 
do  k=0  to  ^ast-l); 

/*  put  item  bytes  into  data  aueue  "^ / 
dat_vect  (k+ of  f)  =  recei ve_data_ block. data (k-+s tart ) ; 
end; 
end; 
end; 

/*  update  local  eve  value  */ 
do  while  (local_evc_value  <  remote_evc_value ) ; 

call  advance  (evcid); 

local_evc_value  =  addZbi  tl6(  local_evc_value  , '0001 '"b4: ) ; 
end; 
end; 

else  do;    /*  if  not  eve  */ 
end; 

call  disable_cTDu_interrupts ; 

end; 

end  process_pack:et; 


ifilii^:i(ii^-if.^-if.-il.-if.ifi'i^'if.ifTl^'i^'if.ifi-i(iififiif-if.':fi^if-ifi:!fiif.:i^ 
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APPENDIX  D 
THE  DRIVER 

The  driver  is  the  software  link  between  a  cluster  and 
the  ECCB  that  hooks  up  a  cluster  onto  the  Ethernet.  It 
manages  all  cluster  external  message  exchange  (transmission 
and  reception) ,  and  sets  up  the  clusters  communication 
ability  in  the  first  place. 

The  driver  resides  in  the  user  area  of  SBC  1,  which  is 
dedicated  to  serve  as  the  cluster's  host.  The  executable 
file  names  are  C1PR0C.CMD  and  C2PR0C.CMD  for  the  two  cluster 
constellation  of  RTC*  in  the  AEGIS  lab  at  the  US  Naval 
Postgraduate  School. 

The  LINK86  Input  option  is  used  to  link  files  sysinitl, 
sysdev,  asmrout ,  and  gatemod  into  CIPROC.  SysinitZ,  sysdev, 
asmrout ,  and  gatemod  are  linked  into  C2PR0C. 

Cluster  specific  information  about  the  creation  and 
distribution  of  eventcounts  is  contributed  by  sysinitl  and 
sysinit2  respectively,  which  are  the  main  procedures  for  the 
linkage.  Additional  cluster  specific  information  is  read 
from  the  address.dat  file  and  the  relation.dat  file  during 
execution  at  runtime.  The  ^included  files  sysdef.pli  and 
NI3010.dcl  provide  system-wide  information. 
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************i(e#**3{£*****j5e*****>it**  **************  *************** 

***  CIPIOC.INP  file  -=='=!= 

*** *** 

***  q,jji5  f^-^^  ^5  ^3g^  ^Q  -^^^^  system  initialization,  *** 
***  driver,  assembly  language  routines,  and  ^atemodule  "•'-'^'^ 
***  into  C1PR0C.CMD,  the  executable  file  run  on  SBC  1  at  -'^'^ 
***  cluster  1 .  =»=*=<' 

*******«***********#*>!e  *;;;***«*********************  *********** 

clproc  = 

sysinitl    [code  [a b  [439]  ]  .data  [ab  [8001  .n[0l  ,ad[62]]  .map  [all  1]  , 

sysdev , 

asmrout , 
gatemod 


********:((**  ********s;e**  *********#******:«(**************:(<*  **?;:** 
**************************************************** *******V: 

*'!'*          Cluster  1  RELATION.DAT  file  --- 

*** *** 

***  This  file  Iceeps  the  data  used  to  build  the  relation   =«'*='' 
***  table:  '^-'•^^ 

***  *** 

***  evc_id    numdat   "Doint      alen      bytes       '''** 
***  *** 

***   col       col       col       col       col        *''•''' 

***     5  ]_5         25         35         45         --* 

********  *:{s:^j}e*******y^  ***************************  ************* 

01  1  8c58        50  6 

03        1         8de4:      50        9 
00         0  0000       00         0 


*************  sjt*  *******  ***s>:****;^^***s):*5;c**************:ie***^-:*** 
****************************  ********:4e  **************:}:***  *>;::;;** 

':=**          Cluster  1  ADDRESS.  EAT  file  --- 

*** *** 

***  This  file  keeps  the  number  of  ?roup  addresses,  **''' 
***  i^Q  cluster's  grouy  address  (es)  and  the  cluster's  '^"■^'^' 
***  source  address.  "^"^"^ 

********>;«*  ****************************};;:<:*******;;{*:;«*  ;;{**5j:j)e**:is:;{ 


1. 

'00e0(7000'b,  'e0^0000i'b, 

'00000(700 'b.  '00000001 'b 


*****************************************;;«  :{«*****j^:^*5;e  ******* 
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**«  SYSINITl.PLI    file  -** 

i^slolt ^^>i' 

«>;<«  This  is  the  system  initialization  procedure  for      **=* 
=****  cluster  1 .  *** 

sysinitl:  proc  options  (rrain)J 

^include  'sysdef .pli '; 
%replace 

EVC_TY?E    by  '00  "b^; 

/*  main  '-^V 

call  define_cluster  ( '0001  "54) ; 

/*  must  he  called  prior  to  creatine  eve's   */ 

/j;j#«j;c    USER    ***!'-/ 

call  create_evc  (TRACK_IN); 

call  create_evc  (TRACK_OUT); 

call  create_evc  (MISSILE_ORDER_IM ) ; 

call  create_evc  (MISSILE_ORDEE_OUT) ; 

/'i**'!'  SYSTEM  ***/ 

call    create_evc    (ERB_RE4D); 

call  create  eve  (ERB_WRITE); 

call  createl'seq  (ERB_WRITE_REOUEST )  ; 

Z"^-   distrih.  man  called  after  eventcounts  have 
he  en  created  •''/ 

call  distrihuticn_map  (EVC_TYPE,  TRACK_IN,  '0003'h4); 

/*  local  and  remote  copy  of  TRACK_IN  needed  */ 
call  distrihution_map  (EVC_TYPE,  MISS  ILE_ORDER_OUT , 

'0003 'h4); 
Z*^  local  and  remote  covy   of  MISSILE_ORDER_OUT 
needed  */ 

/*  create  driver  */ 

call  create_proc  ('fc'D4,  '80'h4, 

'26a5'h4,  '0800'h4,  '005f'h4, 
'0439'h4,  '0S00'h4,  '0e00'h4); 

call  await  ('fe'h4,  '01 'h4); 

end  sysiniti; 
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***  C2PR0C.IM?  file  '="==''•= 

***  This  file  is  used  to  link  system  init  lalizatio  ,  =^-- 
***  driver,  assembly  languaie:e  routines,  and  ^atemodule  "^"^"^ 
***  into  C2PR0C.CMD,  the  executable  file  run  on  SBC  1  at  --* 
***  cluster  2.  ''''^ -"''-' 

c2proc  = 

sy5init2  [code  [ab [439] 1 , data  fab [S00] ,m [0] ,ad [92] ] ,map [all] ] , 

sysdev. 

asmr out , 

gatemod 


******5;e******>jt :<:*:?: 5^4 :^j!sXe*  ********************* *************V*** 

*  *  *  *  *  * ;;;  *  ;;c  *  * ;;;  *  ;;;  *  ;;<  * »;«  ;;;  *  *  *  :;,•  *  *  *  *  *  *  s;;  *  *  *  *  *  j',;  **;;:;;:  *  >;;  *  *  i{i  *  *  * ;;;  ***};:;;;****:;;  ;;j 

'i'-*  Cluster   2    REL  fiTION.DAT    file  -'•-•= 

*l^  'IP  ^P  •■•  ^^•■»  ^iB  mmmmmu  ^b*  an  a^«M*  aaB^^^iB  _^  ^^  mmm  a^  ^iv  ^b  -mb  «■•  ^bb  ^^^^aas^^  *^  ^bb  ^^>^^  s^  ^^  ^^  ^^  as*  ^^  ^^  saw  «—  ^v  ^b^k  ^_  ^^  .^  ^^  ^^  hb^^  ^—  ^iB  ^s  «^  ^b  *|*  ^p   *(• 

***  This  file  keeps  the  data  used  to  build  the  relation  '■^'^''^' 
***  table:  '^'^''* 

***  evc_id    numdat    point     alen      bytes       "^"^"^ 

*  *  *  :^  ^  ^ 

***  ^q]_  ^q-^  ^^-^  j,q]L  col  ''"''* 

***     5         ]_5        25        35        45        --^-i' 

*******};:**:^^9;e  ***************  **>;c  ***********************  ****** 


21 

1 

05 

1 

03 

1 

00 

0 

8c58 

50 

6 

8d94 

20 

3 

9dcd 

50 

9 

0000 

00 

0 

****************  y^**  *********  *************************^>;**  *>;(*:;: 
*3;c3};:{;:^:(e>j:j^^::^3^3;::tt);c***9;:**^*>ic*9tc»;cxc****  ************  ***************** 

**'-         Cluster  2  ADDRESS.DAT  file  --- 

*<s-t  This  file  keeps  the  number  of  sroup  addresses.  *'^''' 
***  the  cluster's  ?rouD  address  (es ), and  the  cluster's  '-^'■^'^ 
***  source  address.  *''-'•' 

*  *:;c*  **  ^c*  :(:****  9;:**  **3(:******;;c**:tc:;c**xc**************************^ 
1, 

'00000000 'b, '00000010  b, 
'00000000'b. '00000010'b 


****  j{c*****  *********************  ********5js**j;s  ******  *********** 
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jjc  3{:  sje  :{e  s;: :{« :{e  >!c  ^  4«  ;}:  s;c  j{c  >;e  s;s  ^  s!<  jje  >;«  >ie  3{e  ;{e  ;;cs;«  sjt  s;«  :{s  *  :{c  :{c  j{s  stssje  sis ;{«  s;t s{e  sf:  sit  sj;  sj!  }*<s  s}:  s)c  jjt  * 

**'«'        SYSINIT2.PLI  file  "^"^"^ 

>^>iss!s n«si":- 

***  This  is  the  system  initialization  procedure  for      *** 
>>=**  cluster  2.  *** 

s}:  sic  s^  s}:  sjc  ^  ^  sjc  sic  :4c  s^  s;:  s^  sj:  :^  s;;  9^  St:  :4c  sj: :(:  :^  s;:  si$  ^  sje  sjc  s{e  ;{e  sit  sje  :^  :jc  sic  s;:  s^  sje  sjc  s;c  sjs  sjc  ;>:  s^e  sic :(:  9^ 

sysinitS:  proc  options  (main); 

%inclule  'sysdef .pli ' ; 

^replace 

EVC_TYPE        by  '00'b4; 

/*  main  */ 

call  def ine_cluster  ( '0002 'M ) ;  /*  must  he  called  prior 

to  creating  eve's   */ 

/siesicjic;}!     USER     ****/ 

call  create_evc 

call  create_evr 

call  create_evc 

call  create_evc 

call  create_evc 

call  create_evc 

/***  SYSTEM  ***/ 


T^.ACK_IM); 

tfj_ck_out); 

missile_ort)?;r_in); 

missils_order_out); 

DELTi»_IN); 
DELTA  OUT) ; 


call  create_evc  (ERE_READ); 

call  create_evc  (ERB_WRITE); 

call  create_sea  (ERB_WRITE_REOUSST ); 

/*  distrib.  map  called  after  eventcounts  have 
been  created  */ 

call  distribution_maD  (EVC_TYPE,  TRACK_OaT,  '0003'b4); 
/*  local  and  remote  copy  of  TRACK_IN  needed  '^/ 
call  distribution_map  (EVC_TY?E,  MISS ILE_ORDER_IN , 

'0003'b4); 
/-  local  and  remote  copy  of  MISS ILE_ORDER_IN  needed  */ 
call  create_-Droc  ('fc'b4,  '8C^'b4, 

'26a5'b4:,  '0800'b4:,  '006b'b4, 
'0459'b4.  '0800'b4,  '0800'b4); 
call  await  ('fe'b4,  '01'b4); 

end  sysinit2; 

;!c  4c  s{t  sjt  sic  5}c  sjt  ;{c  si;  ^  s;t  s;s  sit  sic  s;<  sit  sjt  *  sit  :{c  3;t  :{<  sj:  si^  sic  sit  sit  sje  sic  s{t  sx  sje  sic  *  5}t  s;c  sjc  s;s  sic  sf:  sic  sit  sjc  sic  sic  sje  :{c  5|c :{;  sjs  ^ 
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/**  SYSDEF    FILE  SYSDEF.PLI    David  J.  SPEWEP   1  SEP  84  =^-/ 

/>!«>:<  =  =  =  =  ===:  =  ==  ^  =  =  =  =  =  =  =  =  --  =  =-  =  -=  =  ===  =  =  =  =  =  =  =  =  =  =  =  =-==  =  =  =  =  =  ====  "^'it/ 

/**  This  section  of  code  is  ^iven  as  a  PLI  file  to  be  ^'^Z 

/**  %IMCLUDE'd  with  MCORTEX  user  programs.   ENTRY  'i=*/ 

/♦«  declarations  are  made  for  all  available  MCORTEX  -'V 

/**  functions.  '^*/ 

y- «*:{«  sit  #  :^  3{t  *:{:-:  :)e  >{s  #  :(e  :}e  j<<  « 3^:  #  3):  :{t  «:{;  s}c  :{£  j)t  *  s!e  :}:#,-:;:<!:{«  5}t  #  jf: « -t  sic  s^e  J^ 
/  5!<  >!;  4e  ^'«  :!<  s;<  5|«  ^s  >|c  >|«  5;; ;[«  4e  si*  51;  >le  >;<  ^  3{«  y.;  ;4c  >!<  :<c  j|« :{«  jjc  *  jjc  j{t  y^  :;« :ic ;;{ y^  >I;  y^  sit  :;£  y.t  >!«  j;:  ^ 

DECLARE 

advance  ENTRY  (BIT  (S) ) , 

f^'"   advance  (svent_count_id)  */ 

await  ENTRY  (BIT  (3),  BIT  (16)), 

/*  await  ( event_count_id ,  awaited_value )  */ 

create_evc  ENTRY  (BIT  (S)). 

/*  create^evc  ( event_count_id )  */ 

create_proc  ENTRY  (BIT  (9),  BIT  (S), 

BIT  (16),  BIT  (16),  BIT  (16), 
BIT  (16)  ,  BIT  (16),  BIT  (16) )  , 
/*  create_proc  (  processor_id  ,  processor_  oriority  ,'^/ 
/*  s tack:_pointer_hiehest ,  stack_ses,  ip  */ 

/*         code_seg,  data_seff,  extra_seff)       */ 

create_sea  ENTRY  (BIT  (3)), 

/*  create  sea  (sequence_id )  */ 

preempt  ENTRY  (BIT  (3) ), 

/*  preempt  (processor_id )  */ 

read  ENTRY  (BIT  (8))  RETURNS  (BIT  (16)), 
/*  read  {event_count_id )  */ 
/*  RETURNS  current_event_count  */ 

ticket  ENTRY  (BIT  (8))  RETURNS  iBIT  (16)), 
/*  ticket  ( seauence_id )  "*/ 
/*  RETURNS  uniaue_ticket_value  */ 

iefine_cluster  ENTRY   (hit  U6)), 

/*  def  ine_cluster  ( local_cluster_address  )  "^ / 

distrihution_mai3  ENTRY  (hit  (3),  hit  (3),  hit  (16)), 

/*  distrihuti on_map  (dis trihution_type ,  id, 

cluster  addr)         */ 
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add2bitl6  ENTRY  (BIT(16),  BIT(16))  RETURNS  (BIT  (16)); 
/*  add2bitl6  (  a_16tit_#,  another_16bit_#)  ^/ 
/*  RETURNS  a  16bit  #  +  another  16bit  #     */ 


%replace 
/* 


/*' 


***!=   EVC$ID's  **"' 

(1)  USER  */ 

TRACK_IN  by  '01 '"b4:, 

TRACK_OUT  by  '02'b4, 

MISSILE_ORDER_IN  by  '03'b4, 

MISSILE_ORDER_OUT  by  '04'b4, 

DELTA_IN  by  '05'b4» 

DELT^_OUT  by  '?6'b4. 

/*  (2)  SYSTEM  */ 

ERB_READ  by  'fc'b4, 

ERB_WRITE  by  'fd'b4. 

***    SEQUENCER  NAMES    *** 
(1)  USSR  */ 

/*  (2)  SYSTEM   '^/ 

ERB_WRITE_REOUEST  by    'ff'b4, 

*'«'*      SHARED   VARIABLE   POINTERS      *** 
(1)    USER  */ 


/*         (2)    SYSTEM  */ 

block_ptr_value  by  'B000'b4, 

xmit_ptr_value  by  'S07B'b4, 

rcv_ptr_value  by  '8666'b4, 

END_RESERVE  by  'FFEE'b4; 
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by 

'b0'b4, 

by 

'bl'b4. 

by 

'b2'b4. 

by 

'b5'b4:, 

by 

'b9'b4. 

by 

'bc'b4. 

by 

'bd'b4. 

***  NI3010.DCL  file  =^'^* 

^replace 

/*  I/O  Dort  addresses 

These  values  are  specific  to  the  use  of  the  INTERLAN 
NI301?  MULTIBUS  to  ETHERNET  interface  board.  Any  change 
to  the  I/O  port  address  of  '00b0'  hex  (done  so  with  a  DIP 
switch)   will   reauire   a  change  to   these  addresses   to 
reflect  that  change. 

'^/ 

command_reeister 

command_status_register 

transmit_data_regis ter 

interruDt_statu5_res 

inter rupt_enable_ re  sister 

high_byte_'"ount_reg 

lcw_byte_count_re2 

/*   end  of  I/O  port  addresses  */ 

/*      InterruTJt    enable    status  register   values    */ 
lisable_ni3010_interrupts  by    '00'b4, 

ni3010_intrpts_disabled  by    '0e'b4. 

receive_block:_available  by    '04'b4, 

transmit_dma_done  by    '06'b4, 

receive_dma_done  by    '07'b4, 

/*   end  register  values  */ 

/*   Command  Function  Codes  */ 

module_int erf ace_loopback  by  '01'b4, 

internal_loopback  by  '02'b4, 

clear_loopback  by  '03'b4, 

go__offline  by  '0e^b4, 

go_online  by  '09'b4, 

onboari_diagnostic  by  '0a'b4, 

clr_insert_source  by  '0e^b4, 

load_transmit _data  by  '23'b4, 

load_and_send  by  '29'b4, 

1 oad_group_addresses  by  '2a'b4, 

reset  by  '3f'b4; 

/*   end  Command  Function  Codes      */ 


69 


***         SYSDEV.PLI  file     (driver)  *** 

#  jje  s^s  jje  *  :{e  sjs  ^  ^  #  :<s  « Jie  *  sjs  5)5  s;c  5}e  *  «5:«  i}:  sis  };«*:[«:}!  sje  sj:  j;c  :{e  :;«*«*##  :is  *  sis  *  3{s « j{t  «##  sje :!«  ^  *  sit  *  sie  s^ 


sysiev:  procedure? 

/*  Date:  25  NOVEMBER  1985 

Programmer:       Reinhard  HAEGER 

Module   Function:  To  serve  as  the  Ethernet  Communication 

Controller  Board  ;nI3010)  device 
handler  (driver).  This  process  is 
scheduled  under  MCORTEX  and  consumes 
Ethernet  Reauests  Packets  (ERP) 
generated  hy  the  SYSTEM$IO  routine  in 
LEVEL2.SRC. 

It  creates  a  relation  table  that  keeps 
information  about  the  interrelationship 
between  eventcounts  and  user  shared 
lata,  and  uses  this  information  for 
producing  and  processin,^  Ethernet 
messages. 

This  driver  is  the  version  orovided  by  David  Brewer 
modified  in  order  to  ensure  system-wide  data  sharin,^. 
The  Transmit_Data_Block  and  the  Receive_Data_Block  were 
chan,s:ed  to  keep  1500  bytes  of  data. 

New  procedures  Make_Table  and  Make_Messa^e  were  added, 
and  procedure  Process_Packet  was  completely  changed  to 
provide  cluster  external  user  shared  data  exchan,?e. 
Procedure  Transmi t_Packet  was  modified  to  provide 
flexible  exact  message  length  to  the  ECCB  if  the  length 
is  greater  than  60  bytes,  and  minimum  message  length  if 
the  message  is  60  bytes  or  less. 


%replace 

evc_type  by  '00'b4, 

erb_blbck_len  by  20, 

erb_block_len_ml  by  19, 

infinity  by  32767; 

%include  'sysdef .pli '; 
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DECLARE 


1  ert(  0:prb  ■block_len_ml )  based  (blockptr), 
2  command     bit  (8 ) , 
2  type_name   bit  (8) , 
2  name_value   bit  (16), 
2  remote  addr  bit  (16), 


traasmi  t_da 
2  desti 


2 
2 
2 
2 
2 
2 
2 
2 
2 
2 
2 
2 
2 
2 


desti 
desti 
desti 
dest  i 
desti 
sourc 
sourc 
sourc 
sourc 
sourc 
sourc 
type_ 
type_ 
data 


ta_bl 
natio 
na  tio 
natio 
na  tio 
natio 
na  tio 
e_add 
e_add 
e_add 
e_add 
e_add 
e_add 
field 
field 
(1500 


ock  based 

n_address 

n_address 

n_address 

n_address 

n_address 

n_address 

ress_a 

ress_b 

ress_c 

ress_d 

ress_e 

ress_f 

_a 

_b 

) 


(xmit  Dtr) 


a 

'b 

c 

'd 
e 
■f 


bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 


8) 
5) 
9) 
8) 
8} 
8) 
3) 
9) 
8) 

a) 

6) 
8) 
8) 
8) 
8) 


1  receive_data_ block  based  (rcv_ptr). 


f  ram 
cull 
f  ram 
f  ram 
dest 
dest 
dest 
dest 
dest 
dest 
sour 
sour 
sour 
sour 
sour 
sour 
type 
type 
data 
crc_ 
crc_ 
crc_ 
crc 


e_s tatus 
_byte 
e_lenffth_ 
e_lensth_ 
ination_a 
ina ti  on_a 
ination_a 
ina  tion_a 
ination_a 
ina tion_a 
ce_addres 
re_addres 
ce_addres 
ce__addres 
ce_addres 
ce_addres 
_^field_a 
field_b 
ri500) 
msb 

uDper_mid 
lower_mid 
Isb 


Isb 

msb 

ddres5_a 

ddress_b 

ddress_c 

ddress_d 

ddress_e 

ddress_f 

s_a 

s_c 

s_e 
s  f 


dle_byte 
die  byte 


bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
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eptr  pointer, 

erp_vect(4)  bit  (9)  based  (e_ptr), 

(maxqbytes .bytecount )  fixed  bin  (15), 

rel_tdb{100), 

2  evc_id  bit  (8) , 

2  numdat  fixed  bin  (7) , 

2  data(10) , 

3  point  pointer, 
3  qlen  fixed  bin  (7), 
3  bytes  fixed  bin  (15) , 
3  next_out  fixed  bin  (7), 
3  next_in   fixed  bin  (7). 

(xmit_ptr,  rcv_ptr  ,bloclc_ptr)  pointer, 

index  fixed  bin  (15), 

(addr_e,  addr_f)  bit  (8),    , 

address  file, 

copy_ie_register  bit  (8), 

( cluster_addr ,erb_wri te_value , i )  bit  (16), 

(,1,k)  fixed  bin  (15)  , 

re^_value  bit  (8)  , 

write_io_port  entry  (bit  ^8),  bit  (8)), 

read_io_port   entry  (bit  (3),  bit  (8)), 

ini tialize_cpu_inter rupts     entry, 

enable_cpu_interruDts         entry, 

disable_cpu_interrupts        entry, 

write_bar  entry  (bit(16)); 

/*   end  declaration   */ 


%replace 

/*  codes  soecific  to  the  Intel  8259a  Programmable 
Interrupt  Controller  (PIC)     ""'■/ 

icwl_por t_address  by  'c0'b4:, 

/-  note  that  */   icw2_port_address  by  'c2'b4, 

/*  icw2,icw4,*/   icw4_port_address  by  'c2'b4, 

/*  and  ocw   */   ocw_port_address  by  'c2'b4, 
/*  use  same  */ 
/*  port  addr  */ 

/*  note:  icw  ==>  initialization 

control 
word 

ocw  ==>  operational 
command 
word  */ 
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icwl  ty  '13't4. 

/*  single  PIC  configuration,  el^e 
tri<?eered  input  */ 

icw2  by  '40 '^4, 

/*  most  siffnificant  bits  of  vectoring 
byte;  for  an  interrupt  5, 
the  effective  address  will  be 
(icw2  +  interruDt  # )  =«'  4  which 

will  be  (40  hex  +  5)  *  4  =  Hi  hex 

«/ 

icw4  by  '0f'b4. 

/=*  automatic  end  of  interrupt 
and  buffered  mode/master   */ 

ocwl  by  '8f'fc4; 

/*  unmask  interrupt  4  (bit  4),  '''/ 

/*  interrupt  5  (bit  5),  and  */ 

/*  interrupt  6  (bit  6),  mask  all  others  -/ 

/*  end  P259a  codes  */ 


/*  include  constants  specific  to  the  ^JI301^ 
board  "^f 

^include  'ni3010  .del '; 

/*  Main  Body  =*=/ 

/*  check  message 
put  skiD(2)  list( 'starting  make_  table ')  ;  "^  / 

call  make_table; 

/*  check  message 
put  skip(2)  list( 'make_table  done');  -/ 

call  write_io_port( inter rupt_enable_ register, 

di5able_ni3010_interrupts ) ; 
call  ini tialize_pic; 
call  ini tialize_CDu_interrupts ; 

call  read_io_port  (command_status_refi;ister  ,rei^_valae  ) ; 
call  perform  command  (reset); 
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call  proeram_?roup_addresses ; 
/*  assignments  to  the  source  and  destination  address 
fields  that  will  not  change  */ 

call  perf orm_command  (clr_insert_source) ; 
/=*  NI3010  performance  is  enhanced  in  this  node  */ 


unspec  (block_ptr )  =  hlock_ptr_valiie; 
unspec (rcv_ptr )  =   rcv_ptr_value » 
unspec(xmit_ptr )  =  xmit_ptr_value; 

/*  make  one  time  assignments  to  transmit  data  block  '"•'/ 

transmi  t_data_"block.destination_address_a  =  'P'3'h4; 
transmit_data_block.destination_address_b  =  '00^b4; 
t  ransmi  t_data_block:  .destination_address_c  =  '00'b4; 
transmit_data_block.des tinat ion_addre5S_d  =  '00'b4; 
transmit_data_block .source_address_a  =  '03'b4; 
transmit_data_block .source_address_b  =  '00'b4; 
transmit_data_block  .soiirce_addre5S  c  =  '00'b4; 
transmit_data_block.50urce_address_d  =  '30'b4; 

Z*"  get  the  local  cluster  address  -  file  was 
opened  in  proc  program_group_addresses    */ 

get  file  (address)  list  (addr_e,  addr_f); 
transmit_data_block .source_address_ e  =  addr_e; 
t ransmit_data_block.source_addre5S^f  =  addr_f; 

cluster_addr  =   addr   e    I !    addr_f; 

put  skip  (2)  edit  (''--*  CLUSTE?.  ' .  rlus  te  r_addr  , 

'  Initialization  Complete  **-«') 
(col(15) ,a,b4(4) .a); 
i  =  '0001'b4; 
call  perf orm_command  (go_online); 

/*  at  this  point  copy_ie_reff  =  EBA  ,  but 
ie_reg  on  NI3010  is  actually  disabled  "^i 
call  disable_cpu_interrupts; 

do  k  =  1  to  infinity; 
/*  note:  interruT)t  not  allowed  during  a 
call  to  MCCRTSX  primitive      */ 

erb_writs_value  =  read(EF.B  WHITE); 
/*  In  the  MXTRACE  version"of  the  RTOS 
all  primitive  calls  clear    and 
set  interrupts  (diagnostic  message 
routines),  so  the  MI3010  interrupts 
must  be  disabled  on  entry  to  MXTRACE  */ 
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do  while  (erb_ 

/*  busy  wait! 

erb_wri te_va 

copy_ie_re2i 

call  write_i 

call  enatle_ 

/-^   if  a  pac 

is  when 

see  that 

favored . 

do  j  =  1  to 

/*  interrup 
end;  /*  do  j 
call  disable 
if  (coDy_ie_ 
do; 
/*  receive 
finish, 
call  enabl 
do  while  ( 
end; 

call  disab 
end;  /*  ift 
copy_ie_reffi 
call  write  i 


write_value  <  i ) ; 

n^  */ 

lue  =  read(EFB_WRITE); 

ster=receive_block_available; 

o_port(interrupt_enable_re(fi;ister, 

receive_block:_available) ; 
cpu_interru"Dt5; 
ke t   has   been    received  , this 
an    interrupt   nnay   occur    -   can 
outbound    packets   are   always 

1000; 

t  window  for  rackets  received  */ 

_ci)u_interrupts ; 

register  =  receive_dma_done )  then 

DMA  operation  started,  so  let 

e_cpu_interrupts; 

copy_ie_re?is"ter  =  receive_dma_ione  y  ; 


le_cpu_interruDts; 
*/ 

ster  =  disable_ni3010_interrupts ; 
o_port(interrupt_enable_re^ister, 
di  sablp_ni3<?10_interruDts  ) ; 
end;  /*  busy  ="/ 


/*  EHB  has  an  EPP  in  it,  so  process  it  "^ / 
/*  no  external  interrupts  (RM)  until 
the  EP.P  is  consumed  and  the  packet 
gets  sent  */ 
index  =  mod (( fixed ( i  )  -  1),  erb_block_len  ) ; 
/-^   32k  limit  */ 

transmit_data_block.des tination_address_e= 

substr(erb(index).remote_addr,  1,3); 

trans mit_data_block.destination_address_f= 

substr(erb( index)  .remote_addr,  9,8) ; 

/*  put  overlay  over  ERF  =**/ 
e_"Dtr=addr(  erb  ( index)  .command  )  ; 

call  make_messas:e; 

call  advance  (EHE_READ); 

/*  cauti  on  here  !  ! ! f 

an  ADVANCE  will  result  in  a  call  to  V?$SCHEDULER , 
which  will  set  CPU  interrupts  on  exit. 
It's  the  reason  NI3010  interruuts  are  disabled 
first  in  the  Co  While  loot)  above.   */ 
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/*   packet    ready   to   i?o ,    so    send    it    '^/ 
call    transmi  t_paclret    (bytecount); 

/*   cooy_ie_re^ister=RBA,    but    not   actual    re,^ister   "/ 
call   disa"ble_cpu_interrupts; 

/*   setting   UD    for   next    ER?   consumT)ti  on   */ 
i   =   add2TDitl6(i,    '0001'b4); 

end;      /*   do   forever   */ 

/*  end   main   body   */ 

make_table:    procedure    ; 

declare 

relation  file, 

(.i,i)  fixed  bin  (15), 

eof  bit(3) ; 

onen  file  (relatior)  stream  input; 
i=0; 

eof='0'b4; 

do  while  (eof='0  'b4)  ; 
i=i+i; 

/*  read  data  from  relation.dat  file  */ 
set    file  (relation)  edit (rel_tab( i ) .evc_id , 

rel_tab  ■:  i  )  .numdat  ) 
(column(5),b4(2),column(15),f  i2)  )  ; 
do  j=l  to  ( rel_tab ( i ) .numdat ) ; 

/*  read  data  for  all  related  items  */ 
^et  file  (relation)  edit 

(unspec(rel_tab(i).data(J).point), 
rel_tab(i)  .data(j) .qlen  , 
rel_tab(i) .data( j ) .bytes ) 
(column(25) ,b4(4) , column (35) . f (4) , column (45 ) .f (4) ) ; 
maxa  bytes=max (maxa bytes, 
rel__tab(i)  .iata(  j)  .bytes*rel_tab(i)  .data(  j  )  .alen) ; 
end; 

/*  if  sentinel  is  reached  */ 
if  rel_tab(i ).evc_id  =  '00'b4  then 
do; 

eof='l  'b4; 

put  skip  list ( 'lon,^est  data  queue  at  this  cluster:', 
maxQbytes, '  bytes ') ; 
end; 
end; 
end  make_table; 

/**  ais  **:{«*;;«  s;e  jjs  ;;«*  s;s  si; «  sjt  >!«  5[e  :<{:{:  sj;  ^-t  s;;  jj!  sjt  sje  ajt  sjc  *;;;::««**«**  ^«  sjt  *  sje  *#:({  Jic  sis  5}:  :J:  ;!e  ^ 
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make_messa,^e :  procedure  ' 

declare 

dat_ptr  pointer, 

dat_vect(1500)  bit  (3)  based  (dat_ptr), 

(next_out ,  r  ,,1)  fixed  bin  (7), 

(off  , start  , last  ,k:)  fixed  bin  (15); 

/*  check  for  eve  */ 
if  erp_vect(l)=EVC_TY?E  then 

do; 

bytecoant=4; 
do  k=l  to  4; 

/*  put  eve  info  into  data  field  -"/ 
transni t _data_block.dat a( k )=erp_vect (k ) ; 
end; 


/*  check  message 
put  skip  list (  ' :  : : 


:',transmit_data_block.data(l)  ,  ' 
transmit_data_block.data(2)  ,  ' 
transmit_data_block.data(3j,' 
transmit  data  block  .data (4  ),  ' 


r=i; 

/*  find  respective  relation  table  entry  */ 
do  while  (  (  rel_tab(  r )  .evc_id  '^=  erp  vect(2))  S. 
(rel_tab(r).evc_id  '^=  '00''b4)); 

r=r+i; 
end; 


} » 


/=«'  if 
if  rel_ 

do; 

/*  fo 
do  j=l 
start 
last  = 
bytec 
dat_p 
next_ 

/*  c 
off=( 

/*  c 
rel_t 

do  k= 
/* 
tran 
end; 
end; 
end; 


eve  entry  */ 
tab(r).evc  id 


'=  '00 'b4  then 


r  ever 
to  re 
=bytec 
rel_ta 
ount=b 
tr=rel 
out=re 
ompute 
rei_ta 
ompute 
ab(r). 

0  to  ( 
put  it 
smit  d 


y  related  item  */ 
l_tab( r ) .numdat ; 
ount  -^  i;        /"^ 
b(r  )  .data( j)  .bytes; 
ytecount  +  last;  /* 


find  where  to  put 
/*  how  loHf?  it  is 
keeiD  track  */ 


_tab^  r  )  .data  (j  )  .point ;  /"-align  datvect^-/ 
1_  tab( r ) .data(  ,0  .next_out ; 

offset  of  item  in  data  queue  '-^/ 
b(  r  )  .data(  j  )  .bytes  ""  next_cut)  +  i; 

next  slot  number  to  ao   */ 
data(  j  )  .next_out=mod  next_out  -*-  1, 

rel  tab(r).data(j).alen) 
last-1); 

em's  bytes  into  data  field  */ 
ata  block .da ta ( k+start )=dat  vect(k+off); 
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/*  compute  total  "bytecount  for  message  */ 
t)ytecount=bytecount  +  14; 
end; 

else  do;    /*  if  not  eve  */ 
end; 
end  make_message; 

initialize_pic :    procedure? 

DECLARE 

write_io_port  entry  (bit  (8)  ,  tit(S)); 
call  write_io_"Dort  (  icwl_port_dddress  ♦icwl )» 
call  write_io_port  ( icw2_port_address , icw2) ; 
call  write_io_port  ( icw4_port_address , icw4) ; 
call  wri te_io_port  ( ocw_port_address  ,  ocwl ) ; 

end  initialize_pic  ; 

/  >;e  ;;e  :je :{« :{e  s!e  ;{e  >,■;  ;Jc  >;;  ?;;  >!e  :{t »;« j}e  ^  :{e  :5c  ;Js  sic  sjj  :S  sSt  sjs  ?!<  ir  5»«  *  5<«  s!*  s!*  5'^  T«  5{«  5l<  n«  51*  sJs  sis  Sr  *  ^ 

perf orm_command :  procedure    (command); 

DECLARE 

command  bit  (8)  . 
reff_value  tit  (8)  , 

srf  bit  (8)  , 

write_io_port  entry  (bit  (8)  ,  bit  (8)  ), 

read_io_port   entry  (bit  (3)  ,  bit  (8)  ); 

srf  =  '0'b4; 

call  write_io_Dort  ' command_resister , command  ) ; 

do  while  ((srf  &  '0l'b4)  =  '00'b4); 

call  read  io_port  ( interruDt_status_re^,  srf); 
end;   /*  do  while  */ 

call  read_io_port  ( command_status_reffister ,  re2_value); 
if  (reg_value  >  '01'b4)  then 

do; 

/*  not  (SUCCESS  or  SUCCESS  with  Retries)  '^Z 
put  skip  edit  ( '^'^^'^  ETHERNET   Board  Failure  *** ' ) 
(col(20),a); 
/*  when  this  occurs,  run  the  dia>?nostic 
routine  T3010/Cx,  where  x  is  the 
current  cluster  number  '^Z 
stoT); 
end;  Z*  itd  *Z 

end  perf orm_command ; 

/  3{e «  *  >;c  :{c  }^  ^  s^  :^  *  :{c  s;;  s;e -c -s  ;|t -e  ^«  *  *  s;s :!:  :<t  sjs  ^c  :Jc  #  ^  *  :;c  #  *  sic  ^  * :}:  :{c :}!  sic  :{c  >}e  :}c  *  s;s  *  «  ^  sjc 


78 


transmit_packet :  procedure  (byte_count)  external; 

DECLARE 

p  pointer, 

hyte_co\:nt    fixed    bin    (15)    , 

bytevector (2)    bit    (3)    based    (d), 

srf   bit    (3)    , 

re^_value   bit    (3)    , 

write_io_port  entry  (bit  (3),  bit  (5)  ), 

read_io_port  entry   (bit  (3),  bit  (3)  ), 

enable_cpu_interrupts         entry, 

di 5able_cpu_interrupts        entry. 

write_bar  entry  (bit(16)); 

/*  be^in  */ 
srf  =  '0'b4; 

call  write_bar  (xmit_ptr_value) I 

/*  if  message  lonser  than  minimum  size  */ 
if  (byte_count  >  60)  then 
do; 

p=addr  (  byte_cou'it ) ; 

/*  call  with  exact  bytecount  */ 
call  write_io_port(hish_byte_count_re^,bytevector'2) ) ; 
call  write_io_port(  lo¥_byte_count_re,?,  byte  vector!  1 )  ) ; 
end; 

/*  if  message  is  not  longer  than  minimum  size  */ 
else  do; 

/*  call  with  minimum  bytecount  of  60  =*/ 

call  write_io_port(hiffh_byte_count_res,  '.30 'b4:)  ; 

call  write_io  port  ( low_byte_count_re2;, '3c 'b4) ; 
end; 

coDy_ie_reffister  =  t ransmit_dma_done ; 

call  write_io_port( inter rupt_enable_ register, 

transmit_dma_done); 
call  enable_cpu_inte rrupts ; 

do  while  ( copy_ie_register  =  transmi t_dma_done ) ; 
end;    /*  loop  until  the  interrupt  handler 
takes  care  of  the  TDD  interruDt  - 
it  sets  copy_ie_register  =  RBA  */ 
call  perf orm_command  ( load_and_send  ) ; 
put  skip  li st ( 'transmitting' ) ; 
end  transmit_packet ; 
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HL_interrupt_handler :  procedure  external; 

/*  This  routine  is  called  from  the  low  level 
8086  assembly  lan,£ruaffe  interrupt  routine  */ 

DECLARE 

write    io_port   entry    (hit    (8),  hit    (8)    ), 

read_io_-Dort   entry    (hit    (6)    ,  hit    (8)    ), 

enahle_cpu_interrupts  entry, 

disahle_cpu_inter ruDts  entry, 
write_har  entry    (hit(16)); 

/*      he^in        */ 

call   write_io_"Dort  (  in  terruT)t_enahle_resister, 

disahle_ni3010_interrupts); 

if    (copy_ie_re£rister   =   receive_hlock_availahle )    then 
do; 

call  write_har  i rcv_ptr_value) ; 

call  write_io_port  (  hi(S;h_hyte_count_rei^,  '25  'h4)  ; 

call  write_io_port(low_hyte_count_re?, 'f2'h4); 

/*  initiate  receive  DMA  "^ / 

copy_ie   register    =  receive_dma_done ; 
call   write_io_port  (  interruot_enahle_ref?ister  , 

receive_dma_done ) » 

end;        /*  do   */ 

else 

if  (copy_ie_register  =  receive_dma_done )  then 

do; 

call  process_packet ; 

copy_ie_re,s:ister  =  receive_hlocic_avai  lahle  » 
call  wri te_io_port ( interrupt_enahle_re^ister  , 

receive_block:_availahle ) ; 

end;  /"^   if  then  do  */ 

else 

if    (cooy_ie_reffist er    =   transmi t_dma_done  )    then 

do; 

coT)y_ie_register    =   receive_hlock:_availahle ; 
/*    NI3010   interrupts   disabled    on   entry   */ 
end;        /*    if    then   do   -V 

end  HL_interrupt_handler ; 

/sif  vjf  »ft  W^  tff  %t^  0«  «*«  «V  WV  ^'^  ^^  *^  V*  ^'  ^V  *^  ^^  ^^  ^^  ^V  ^^  ^y  ^f  ^^  ^^  ^*'  *^  ^*  yf*  ^'  ^^  ^^  ^V  *^  V^  ^''*  "^^  ^V  >^  ^'  ^V  ^f  ^'  ^V  V'  ^^  *^  <^^  ^*^  *•*'  ^^  ^V  ^'«  kJU  «■*'  V^  ^'     / 
O*  ^(*  *!*  *^  *i*  ***  I*  't*  "p  o*  '(*  ^*  'f*  *1*  'i*  *i*  ^*  '»*  ^r  'I*  '(*  '4*  ^  ^r  'i*  *^  ^^  1"*  o*  *!*  ^*  ^  'I"*  'n  'I*  *l*  'tf*  1'"  1*  'R  1*  *^  •!!*  1*  '1^  ^'*  '^^  "If*  IP  **•  'f*  'P  *1P  '**  *•*  1*  'T'  '1*    / 
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process_pack'et :    procelurej 

DECLARE 

evcil  tit  (6) , 
local_evc_value  "bit  (16), 
(dat_ptr,D)  Dointer, 
re'note_evc_value  bit  (16)  based  (p), 
dat_vect ( 1500)  bit  (8)  based  (dat_ptr), 
(off , start, last  ,k:)  fixed  bin  (15), 
(next_in,  r  ,.i )  fixed  tin  (7); 
put  skip  list ( 'receiving' ) ; 

/*  check  for  eve  */ 
if  receive_data_block.data (1 )=evc_type  then 
do; 

p  =  addr ( receive_dat a_block .data ( 3) ) ; 
evcid=receive_iata_block.data(2); 
local_evc_valae  =  read(evcid)» 
if  local_evc_value  <  remote_evc  value  then 
do; 
r=i; 

/*  find  eve  entry  in  relation  table  */ 
do  while  (  (  rel_tab  (r  )  .evc_id  ''=  evcid)  8. 
(rel_tab(r).evc_id  ^=    %O0'b4)); 
r=r+i; 
end; 
if  rel_tab(r)  .evc_id  ''=  '00 'b4  then 

do; 

bytecount=4;   /''-  jump  over  eve  info  */ 

do    ,1  =  1    to    rel_tab(  r )  .numdat ; 

start=bytecount+l ;  /*  compute  start  of  ite^i  */ 
last  =  rel_tab  (r  ^  .data(  j  )  .bytes;  /'^  and  length  */ 
bytecount  =  bytecount  +  las  t;  /*  and  item's  end  ^-f 
next_in  =  rel_tab(r).data(.i).next_in; 

/*   comoute    offset    in   data   aueue    -'- / 
off=( last*next_in)    +   i; 

/"*   compute    next    slot    nuTibeT*    to    fill    */ 
rel_tab( r ) .data ( j ) .next_in=mod 'next_in+l, 

rel_tab(r).data(j).alpn); 

dat_-Dtr=rel_ta  b(  r  )  .data  (  j  )  .point ;    /*  alic^n    latvect*/ 

do   k=0   to    (last-1); 

/*  put  item  bytes  into  data  oueue  */ 
dat_veet(k  +  off)  =  receive_data_block.tiata(k  +  start); 
end; 
end; 
end; 
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/*  update  local  eve  value  */ 
do  while  ( local_evc_value  <  remote_evc_value  )  ? 

call  advance  (evcid); 

local_evc_value  =  add2bitl6 (local_evc_value , '0??1 'b4) ; 
end; 
end; 

else  do;    /*  if  not  eve  */ 
end; 

call    di5able_c pu_int errupts ; 

end; 

end   proce5s_paclcet ; 

pr 0 sra 'n_gr 0 up _ad dresses  :    TJrocedure; 
DECLARE 


1  2roup_addr(40)  based  (ffroup_ptr), 
2  Tic_^rouD_f ield_ 
2  mc_^roup_f ield' 
2  mc_sroup_f ield 
2  mc_sroup_f ield 
2  mc_sroup_f ield 
2  mc_£rroup_f ield^ 


lECLARE 

(^roup_pt r,p)  poirter, 

(field_e,  field_f)  bit  (8), 

bit_8_ffroups  bit  (8)  based  (p), 

(i  .num_^roups  .,E:roups_ti.rnes_6)  fixed  bin  (?)» 

unsDec  (ffroup_ptr  )  =  xrrit_Dtr_value; 
open  file  (address)  stream  input; 
^et  file  (address)  list  (nurD_^roups ) ; 
do  i  =  1  to  num_,?roups ; 

group_addr( i ) .mc_sroup_f ield_a  =  '03'b4; 

e;roup_addr(  i  )  .mc_^roup_f ield_b  =  '00'b4; 

grouTD_addr(  i  )  .mc_?roup_f  ield_c  =  '00'b4; 

group_addr( i ) .mc_group_f ield_d  =  '00 'b4; 
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a 

bit 

(B), 

b 

bit 

(8), 

c 

bit 

(8). 

d 

bit 

(8). 

e 

bit 

(3), 

f 

bit 

(8); 

get  file  (address)  list  ( f leld_e , fi9ll_f ) ; 
?rouD_addr( i ) .mc_ffrouD_f ield_e  =  field_e; 
group_addr( i  )  .mc_group_f ield_f  =  field_f; 

end;     /*  do  i  '«'/ 

call  disable_cpu_interruDts ; 

call  write_bar  ( xmit_ptr_value ) ; 

call  write_io_port  (hiffh_byte_count_reg,  '30''b4); 

groups_times_6  =  6  *  num  frroups; 

p  =  addr  (groups_times _6T; 

call  write_io_port(  low_'byte_count_reg,  t)i  t_8_^roups  ) ; 

coDy_ie_re,6ris  ter  =  tran5mit_dma_done; 

call  vri te_io_po  rt ' i  nterrupt_enable_register , 

tran5mit_dma_done)i 
call  enal)le_cpu_interruDts ; 

do  while  (  copy_ie_re,eister  =  transmi  t_lma_dor.e  )  » 
end;    /*  loop  until  the  interrupt  handle^ 

tak:es  care  of  the  TDD  interruDt  - 

it  sets  CO?Y_IS_REG  =  R3A   */ 

call  perf orm_command (1 oad _gr o up _ad dresses ) J 


end  proffram_group_addresses f 


end;    /*  system  device  handler  and  packet  processor 
(driver)  */ 


sjc #  s^e >;;  sjj ;;; ^  j;e  jjs  ^  };<  s;e}'^  ^ItSc »!-  Jje  ;;<:{£  j{e  i!;?}:  ::;^i;t^ sjc ^ ^c  ;;«s}: >;i  jJijIs  ijc  y,c  5^:{{  ;^  ;;:^;  ^  ^ 5!;  s); ^,i  ^ :^,i  r;s ^<  :;«5;< ;;: :;;  sj; ;!: s;j s;: :;: ;;: :;« 
sje »;;  >j:  5;e  s;t  >;«»;«  ;{e  >;<  :'^  >;«  y^  >!e  ^  >;:  sit  >^  #:;«  >^  5"^  >;«  ^'t );« :<c  >;«  >j:  >;e  >J< :(«:{:  ;'^  >;t  >;:  V  Jr  »r  >(<  ^  >1J  ^  >i' >;:  5? 

***  ASMROUT.Aee  file  -'^^^ 

»!«>;«  ^  sjs :{«  ;'^  s;e  s;c  ;;s  i'fi  jjs  $;{»!<>}:  ^  >]i  sts  j(!  sjs  >;{  s[c  sje  >):  >!;  s;«  >;<  sjc  5{«  >[<  j;c  j',: ;;« ;):  >!«  >i«  ;;:  s{c  i'fi  j,-  i[i  :(s  jJj  ^;  :;<  ri^  ;;j  5;:  si:  >;;  ^:  j".; :;; :;« :;: :;;  a;: ;;;  y,; ;;;  ifi 


extrn  hl_interrupt_ handler  :  far 

Dublic  write_io_port 

public  read_io_port 

■Dublic  write_bar 

public  initialize_cpu_ interrupts 

public  enahle_cpu_interrupts 

public  disable_rpu  interrupts 
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write_io_port : 

;  Parameter  Passing  Specification: 

entry  exit 

parameter    1  <port    a(ilress>  <'unchdn2ei> 

parameter   2  <value    to   "be    outputted>      <unchari,^9l> 

dseg 

port_address    rb   1 

cses 

push  tx!    push   sil    Dush   dx!    push   ax 

mov      si ,    [bx] 

mov     al»    [si] 

mov      port_addre5S ,    al 

mov      si,    2[bx] 

mov      al,    [sil 

mov      dl,    Dor t_address 

mov      dh,    00h 

out      dx ,    al 

pop  ax!  pop  dx !  poD  si!  pop  bx 

ret 

read_io_port : 

Parameter  Passing  Specification 

entry  exit 


parameter  1 
parameter  2 


<iDort  address> 
<meaningless> 


<unchanged> 
<register  valued 


cseg 

push   bx!    push   si!    rush   dx !    push   ax 

mov      si,       [bx] 

mov      al,       [si] 

mov      port_address ,      al 

mov      si,    2[bx] 

mov      dl,    port_address 

mov     dh,      00h 

in       al,      dx 

mov      [si] ,    al 

poD      ax!    poD   dx!    pop    si!    pop   bx ! 

ret 


84: 


write  bar: 


Parameter  Passing  Specification 

parameter  1  (and  only):  the  address  of  the  data  block: 

to  be  transmitted  or  received 

dsee 

e_bar_port  eau  0b9h 

h_bar_port  eau  0bah 

l_bar_port  equ  3bbh 

temp_e_byte  rb  1 
te'np_es          rw        1 

cse,? 

J  This  module  comDutes  a  24  bit  address  from  a  32  bit 
»  address  -  actually  it's  a  combination  of  the  ?S 
?  register  and  the  IP  passed  via  a  parameter  list.- 

Dush  bx !  push  ax!  push  ex  I  oush  es !  Dush  dx I  push  si 


mov  dx,   0800h       J  shared  memory  segment 

mov  es,   dx 

mov  temp_es  ,  es 

mov  dx,   es 

mov  si,   [bxl 

mov  ax,   [sil 

mov  cl,   12 

shr  dx,   cl 

mov  temD_e_byte,    dl 

mov  ix,   temp_es 

mov  cl,   4 

shl  Ix,   cl 

add  ax,   dx 

,]nr.  no_add 

add_l:     inc  temp_e_byte 

no_add:    out  l_bar_Dort,  al 

mov  al ,  ah 

out  h_bar_port,  al 

mov  al ,  temp_e_byte 

out  e_bar_port ,  al 

pop  si!  pop  dx !  pop  es!  pod  cx !  poD  ax!  pop  bx 

ret 


•  :fii:(fi!fJlfyi/!i)ii)iiii;ffi)i)iilp3)ii)iiiij;iiiji3tfi)i^T((ii)f::^3t:i!i:iii3)iyii3): 
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initial!  ze_CT)u_interruDts : 

I  Module  Interface  Specification: 

;      Caller:        Ethertest (PL/I )  Procedure 

;     Parameters:     NONE 


initmodule  cseg  common 
OTS    114:h 

int5_offset    rw  1 
int5_sef:ment   rw  1 

cse? 

push  tx 

push  ax 

mov  bx ,   offset  interrupt_handler 

mov  ax ,   0 

push  ds 

nov  ds  ,   ax 

mov  ds  :int5_off set ,  bx 

mov  hi,  cs 

mov  ds  :int5_se£ment ,  hx 

pop  ds 

pop  ax 

pop  hx 

sti 

ret 


enahle_cpu_interrupt s : 

;  Module  Interface  Specification: 

;     Caller:  Ethertest ( PL/I )  Procedure 

;      Parameters:  NONE 


sti 
ret 


•  3|C3|C3Acdc^M3)c^s£csSe3{«^3Cc;£e9te3Qc«fie9^3fic3!£«^ 
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lisable_cpu_interrupts  : 

Moclule  Interface  Specification: 

Caller:        Ethertes t (PL/I )  Procedure 
Parameters :    none 


cli 
ret 


J  :ffi;fiii:^:ii:f/i:(f^^i^i!:j^i!fi)ii^i^i^,:(;iy;/:i^ii^yfi\iiX!i'^y^i!fii)i:^,i^ 


interruDt  handler: 


;  IP,  CS,  and  fla^s  are  already  on  stack 
;  save  all  other  registers 

push  ax 

push  bx 

push  ex 

push  dx 

push  si 

push  di 

push  bp 

push  ds 

push  es 

call  hl_interrupt_handler 

;  hi^h  level  source  routine 
;  In  Ethertest  ^^odule  (PL/I) 

»  restore  re,^isters 


es 
ds 
hp 


pop 
pop 
pop 
pop  di 
pop  si 
pop  dx 
pop  ex 
poD  hx 
poT)  ax 
sti 
iret 


end 


•  *>;<*»;;  jj:  *«  };e  :;e  *  ;;j  5;;  ij:  :;e  ;;:#*  5!e  jj:  j^  *  sf:  j;c:Je::tj!e:{c>>:sJ::J:^  *;;;:)£ ;;;};« J}:  5:!j;c^:<;};c>;:3>:^'c:;s  5^ 
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*  GATEMOD    /    GATETRC        File    (JATEM/T.aSe      BREWER    1    SEP      84    -/ 

}»: _5{e/ 

^   This  module  is  given  to  the  user  in  ob,1  form  to  link  */ 

*  with  his  initial  and  process  nodules.   Any  chan,^e5  to  */ 

*  user  services  available  from  the  OS  must  be  reflected  '-^Z 

*  here.   In  this  way  the  user  need  not  be  concerned  with  */ 

*  actual  CtATEKEEPER  services  codes.   Two  lines  of  code  */ 

*  are  contained  in  conditional  assembly  statements  and  */ 

*  control  the  output  to  be  GATEMOD  or  GATETRC  depending  */ 

*  on  the  value  of  GATEMOr  at  the  code  start.  -/ 

*  This  module  reconcile?  parameter  passing  anomalies      */ 

*  between  MCORTEX  (written  in  PL/M)  and  user  programs    */ 

*  (written  in  PL/I)  .  */ 

•)•____  —  ^^_^— _— ._— ^___^^__  — __^  —  ______-.^_^___^___^___.— ^_  — _— —  _..,•./ 

*  m  calls  are  made  to  the  GATEKEEPER  in  LSVEL2  of  the   -/ 

*  OS.   The  address  of  the  GATEKEEPER  must  be  given  below.*/ 
* t'  / 

*  The  ADD2BIT16  function  does  not  marce  calls  to  MCO^.TEX.  */ 

*  It's  Durpose  is  to  allow  the  addition  of  two  unsigned   */ 

*  16  bit  numbers  from  PL/I  programs.  */ 

DSEG 

GATEMOD  EOU  0  ;***  SET  TC  ZERO  FOR  GATETRC 

;***  SET  TO  ONE  FOR  GATEMOD 
PUBLIC  ADVANCE       ;*'^'i'  THESE  DECLARATIONS  MAKE  THE 
PUBLIC  AWAIT         ;-'^*  GATEKEEPER  FUNCTIONS  VISIBLE 
PUBLIC  CREATE_EVC    ;-**  TO  EXTERNAL  PROCESSES 
PUBLIC  CREATE_PROC 
PUBLIC  CREATE  SEO 
PUBLIC  PREEMPT 
PUBLIC  READ 
PUBLIC  TICKET 
PUBLIC  DEFINE_CLUSTFR 
PUBLIC  DISTRIBUTION_MAP 
PUBLIC  ADD2BIT16 

AWAIT_IND  ECU  2  ;  ***  THESE  aPE  THE  IDENTIFIC '^-TION 

ADVANCE_IND  EQU  1        ; **^  CODES  RECOGNIZED  BY  THE 

CRSATE^EVC_IND  EOU  2     ;**-  GATEKEEPER  IN  LEVEL  II  OF 

CREATE  SEO_IND  ECU  3     ;  *'««'^  MCORTEX 

TICKET_IND  EOU  4 

READ_IND  ECU  5 

CREATE  PROC_IND  EOU  6 

PREEMPT_IND  EQU  7 

DEFINE_CLUSTER_IND  EOU  9 

DISTRIBUTION  MAP  IND  ECU  9 
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IF  GATEMOD 

GATEKE5PSR_IP  DW  0236H 

GATEKEEPER_CS  DW  0BADH 

ELSE 

GATEKEEPER_IP    DW    0068H 

GATEKEEPEP_CS    DW    0B4CH 

ENDIE 

GATEKEEPER    EOU    DWORD    PTR    GATEKEEPER_I P 

CSEG 


;####    1    ####   ^■ 


;♦'»:*    ^'inf^IT    «**    AWAIT    **'''    AWAIT    ***    AWAIT    ***    AWAIT    ^'-^^^^^''-f^/ 


PUSH    ES 

MOV    SI,2[BXl 

MOV    BX,  [BX] 

MOV    AL.AWAIT_IND 

PUSH    AX 

MOV    AL,  [BX] 

PUSH    AX 

MOV    AX, [SI] 

PUSH   AX 

PUSH    AX 

PUSH   AX 

CALLF    GATEKEEPER 

POP  ES 

RET 


;SI  <—  PNT  TO  COUN'T  AV'AITED 
;BX  <—  PNT  TO  NAME  OF  EVENT 

;N  < —  AWAIT. INDICATOR 

;BTT  < —  NAME  OF  EVENT 
;AX  <—  COUNT  AWAITED 
;WORDS  <~  COUNT  AWAITED 
;PTR_SEG  < —  UNUSED  WORD 
;PTR  OFFSET  <--UNUSED  WORD 


;**«  ADVANCE  ***  ADVANCE  ***  ADVANCE  *'•'*  ADVANCE  «***«***«*/ 


ADVANCE: 


PUSH  ES 

MOV  BX,  [BX] 

MOV  AL,ADVANCE_IND 

PUSH  AX 

MOV  AL,  [BX] 

PUSH  AX 

PUSH  AX 

PUSH  AX 

PUSH  AX 

CALLF  GATEKEEPER 

POP  ES 

RET 


;BX  <—  PTR  TO  NAME  OF  EVENT 

;N  <~  ADVANCE  INDICATER 

;BYT  <—  NAME  OF  EVENT 
;WORDS  <—  UNUSED  WORD 
;PTR_S?G  <~  UNUSED  WORD 
;PTR  OFFSET  < — UNUSED  WORD 
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;***   C?.EATE_EVC    ***    CEEATE_EVC    ***    CREATE_EVC    *******;-**«=}«#*/ 
CREATE   EVC: 


PUSH    ES 

MOV    BX,  [BX] 

MOV    AL,CREATE_EVC_IND 

PUSH   AX 

MOV   AL,CBX1 

PUSH    AX 

PUSH   AX 

PUSH   AX 

PUSH    AX 

CALL?    GATEKEEPER 

POP    ES 

RET 


;***  CREATE_SEO  ***  CREATE_SEO  ***  CREATS_SEO  ***':'*«'!--****'^*/ 
CREATE  SEO: 


;BX  <—  PTR  TO  NAME  OF  EVENT 

;N  <--  CREATE_EVC  INDICATOR 

;BYT    < —    NAME   OF    EVENT 
;WORDS    <~   UNUSED    *ORD 
;PTR_SEG    <—  UNUSED    WORD 
;PTR   OFFSET    < — UNUSED   WORD 


PUSH    ES 
MOV    BX    [BX] 

MOV  al!create_seo_ind 

PUSH  AX 

MOV  AL,  [BX] 

PUSH  AX 

PUSH  AX 

PUSH  AX 

PUSH  AX 

CALLF  GATEKEEPER 

POP  ES 

RET 


;***  TICKET  ***  TICKET  ***  TICKET  '^**  TICKET  ***  TICKET 
TICKET: 


;BX  <—  PTR  TO  NAME  OF  SEO 

;N  < —  CREATE_SEO  INDICATER 

;BYT  < —  NAME  OF  SEO 
;WORDS  <—  UNUSED  WORD 
;PTR_SEG  <--  UNUSED  WORD 
;PTR  OFFSET  <— UNUSED  WOHD 


'  ^  *!* 


PUSH   ES 

PUSH    ES 

MOV    CX,SP 

MOV   BX,  [BX] 

MOV  AL,TICKET_IND 

PUSH   AX 

MOV    AL,  [BX] 

PUSH   AX 

PUSH   AX 

PUSH   SS 

PUSH    CX 


; TICKET  NUMBER  DUMMY  STORAGE 
;?OINTER  TO  TICKET  NUMBER 
I  EX  <—  PTR  TO  TICKET  NAME 

;N  <—  TICKET  INDICATER 

;BYT  < —  TICKET  NAME 
;  WORDS  <—  UNUSED  WORD 
;PTR_SEG  <—  TICKET  NUMBE?  SEG 
;PTR  OFFSET  <—  TICKET  NUMBER  POINTER 
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CALLF  G/^TEKEEPER 
POP  BX 
POP  SS 

RET 


;retrieve  ticket  nqmber 


;*««    READ    ***    READ    ***    READ   =«'=^*    READ    '^'^'^    PEAD    *'^*    READ    =''***/ 
READ: 


PUSH   ES 

PUSH    ES 

MOV    CX.S? 

MOV    BX,  [3X] 

MOV    AL.RSAD_IND 

PUSH    AX 

MOV    AL,  [3X] 

PUSH    AX 

PUSH    AX 

PUSH    SS 

PUSH   CX 

CALLF   GATEKEEPER 

POP  BX 

POP  ES 

RET 


JEVENT  COUNT  DUMMY  STORAGE 
;POINTER  TO  EVENT  COUNT 
;BX  <~  PTR  TO  EVENT  NAME 

;N  < —  READ  INDICATSR 

;3YT  < —  EVANT  NAME 

;BYT  < —  UNUSED  WORD 

;PTR_SSG  < —  EVENT  COQ^JT  SEGMENT 

;PTR_OFFSET  < — EVENT  COUNT  POINTE? 

;RETRIEVE  EVENT  COUNT 


;***  CREATE_PROC  ***  CREATE_PROC  **"  CREATE_PROC  ^f'^^^^^^^^^-f / 

C?EATE_PROC: 

PUSH    ES 

MOV    SI,14[BX] 

PUSH    WOPD    PTR    [SIl 

MOV    SI  ,12[BX] 

PUSH    WORD   PTR    [SIl 

MOV    SI.    10[BXl 

PUSH    WORD   PTR     [SI] 

MOV    SI,    9[BXl 

PUSH    WORD    PTR    [SIl 

MOV    SI ,    6[BX] 

PUSH    WORD    PTR     [SI] 

MOV    SI ,    4r3Xl 

PUSH    WORD    PTR    [SI] 

MOV    SI,2[3X] 

MOV    AH.  [Sr 

MOV    SI ,  [BX 

MOV    AL,  [SI] 

PUSH    AX 

MOV    CX.SP 

MOV    AL, CREATE    PROC    IND 


;SI  <—  PTR  TO 

PROCESS 

ES 

;STACK  PPOCESS 

ES 

;SI  <—  PTR  TO 

PROCESS 

DS 

;STACK  PROCESS 

DS 

;SI  <—  PTR  TO 

PROCESS 

CS 

;STACK  PROCESS 

CS 

;SI  <—  PTR  TO 

PROCESS 

I? 

;ST«CK  PPOCESS 

IP 

;SI  <—  PTR  TO 

PROCESS 

SS 

;STACK  PROCESS 

SS 

;si  <—  PT?  TO 

PROCESS 

SP 

;STACK  PROCESS 

S^ 

;SI  <—  PTR  TO 

PROCESS 

PRIORITY 

;GET  PROCESS  PRIORITY 

;SI  <—  PTR  TO 

PROCESS 

ID 

;GET  PROCESS  ID 

;STACK  P^OCFSS 

PRIORITY  AND  ID 

;POINTER  TO  DATA 
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PUSH 

AX 

PUSH 

AX 

PUSH 

AX 

PUSH 

SS 

PUSH 

CX 

CALLF   GATEKEE 

PER 

ADD    i 

5P,14: 

POP    ] 

ES 

;H    <—  CREATE  PROCESS  IND 
;BYT  < —  UNUSED  WORD 
;WORDS  <—  UNUSED  WORD 
;PROC_PTR  SEGMENT  <—  STACK  SEG 
;PROC_PTR  OEFSET  < —  DATA  POINTER 

;REr^OVE  STACKED  DATA 


RET 


;5!s##  PREEMPT  ***  PREEMPT  ***  PREEMPT  ***  PREEMPT  ****»!";«*-:'•**/ 


PREEMPT: 


PUSH  ES 

MOV  BX.  [BX] 

MOV  AL,PRESMPT_IND 

PUSH  AX 

MOV  AL, [BX] 

PUSH  AX 

PUSH  AX 

PUSH  AX 

PUSH  AX 

CALLF  GATEKEEPER 

POP  ES 


;BX  <—  PTR  TO  NAME  OF  PROCESS 

;N  < —  PREEMPT  INDICATER 

;BYTE  < —  PREEMPT  PROCESS  NAME 
; WORDS  <--  UNUSED  *ORE 
;PTR_SEG  <—  UNUSED  WORD 
;PTR  OFFSET  <—  UNUSED  WORD 


RET 


DEFINE  CLUSTER  *** 


DEFINE  CLUSTER  '•"^''* 


DEFINE  CLUSTER: 


PUSH 

ES 

MOV 

BX, 

[BX] 

MOV 

AL, 

DEFINE_CLUSTF 

'R 

PUSH 

AX 

PUSH 

AX 

PUSH 

WORI 

)   PTR    [BX] 

PUSH 

AX 

PUSH 

AX 

CALLF   GATEKEEPER 

POP 

ES 

RET 

;BX  <—  PTR  TO  LOCAL$CLUSTER$ADDR 
IND 

;N  <—  DEFINE  CLUSTER_IND 
;3YT  <--  UNUSED  WC^D 
;WORDS  <--   LOCALiCLUSTER$ADDR 
;PTR_SEG  <--  UNUSED  WORD 
;PTR  OFFSET  <--   UNUSED  WORD 
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;***    DISTRIBUTION_MAP    ***    D ISTRI  BUTGN_MA?    *-=«'     -*/ 
DISTRIBUTION  MAP: 


;SI  <—  PTR  TC  GROUP  ADDRESS 

;STACK  THY  GROUP  ADDKI33 

;SI  <—  PTR  TO  ID  OF  MA?_TY?3 

;SI  <—  PTR  TO  MAP_TYPE 
;AL  <—  MAP_TY?E 
;STACK  ID  AMD  MA?_TY?I 
; POINTER  TO  DATA 
MAP_IND 

;N  < —  DISTrIB_MA?_IND 
;PYT  <--  UNUSED  WORD 
;WORD  <—  UNUSED  WORD 

;map_ptr_seg  < —  ss 

;MAP  PTR  OFFSET  <—  DATA  PTR 


PUSH  ES 

MOV   SI, 

4[BXl 

PUSH  WORD  PTR  fSI] 

MOV   SI, 

2[BX] 

MOV   AH, 

[SI] 

MOV   SI, 

[BX] 

MOV   AL, 

[SI] 

PUSH  AX 

MOV   CX, 

SP 

MOV   AL, 

DISTRIBUTION 

PUSH  AX 

PUSH  AX 

PUSH  AX 

PUSH  SS 

PUSH  CX 

CALLF  GATEKEEPER 

ADD   SP, 

4 

POP   ES 

RET 

;*t««  ADD25IT16  **-  ADD2BIT16  *-*  ADD2BIT16  ^**  ADD2BIT16  -=*=/ 

ADD2EIT16: 

MOV    SI,[BXl  ;SI    <—   PTR    TO    3IT(16)#1 

MOV    EX,2[PX]  ;EX    <—   PTR    TO    BIT(16)^ki 

MOV    BX,rBXl  ;BX    <~    BIT(ie)^2 

ADD    BX,rSIl  ;BX   <—    BIT(16)#1    +    BIT(16)=*2 

RET 

END 


•  ^3t:34'»l<3t'##4:#3((^<:#3>:^it:>r>((3t(ii(>r>i<>rX''!':(c>Sc^^^>i(:(<s^>^»lc»i:>^>!:X:34e^^#iien:^3(:#^>S'^ 
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APPENDIX  E 
THE  DEMONSTRATION  PROGRAM 

The  demonstration  program  is  a  combination  of  four 
modules  that  simulate  gathering  and  processing  track 
information  and  calculating  direction  and  launcher  number 
for  missile  launchers. 

It  was  not  a  goal  of  this  demonstration  program  to 
provide  a  valid  algorithm  for  a  real  system,  but  rather  to 
show  the  synchronization  of  distributed  asynchronous 
processes  with  different  execution  times,  working  with 
different  length  shared  data  queues,  that  reside  at 
different  addresses  at  different  clusters.  Another  goal  was 
to  demonstrate  the  systems  ability  for  processes  working  in 
shared  buffers,  or  with  local  copies  of  shared  data  items, 
or  a  combination  of  both. 

Process  trkdetec  simulates  the  track  detection  by 
producing  x,  y,  and  z  track  data.  The  track  information  is 
put  into  the  50  slot  queue  TRACK. 

Process  trkrprt  simulates  the  track  movement  calculation 
by  producing  dx,  dy,  and  dz  values  from  the  comparison  of 
two  consecutive  track  informations.  It  consumes  TRACK  data 
and  puts  delta  information  into  the  20  slot  queue  DELTA. 

Process  mslorder  simulates  the  missile  launcher 
direction  calculation.  It  consumes  TRACK  data  and  DELTA  data 
and  combines  these  into  simulated  azimuth  and  elevation 
information  and  assigns  a  launcher.  These  data  are  put  into 
the  50  slot  queue  MISSILE_ORDER. 

Process  msltrain  simulates  the  missile  launcher  training 
by  consuming  MISSILE_ORDER  data  and  displaying  launcher 
number,  launch  number,  azimuth,  and  elevation. 

For  demonstration  purposes  each  process  displays   its 
calculated  values  and  its  status  (e.g.  waiting,  going,  done. 
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queue  full ,  etc. ) 

The   program  was   successfully  run   in  three   different 
constellations : 

1.)  Process  trkdetec  and  process  msltrain  multiplexed  on 
one  SBC,  and  process  trkrprt  and  process  mslorder 
multiplexed  on  a  second  SBC  in  the  same  cluster  (cluster  2). 

2.)  Process  trkdetec  and  process  msltrain  multiplexed  on 
one  SBC  in  cluster  1,  and  process  trkrprt  and  process 
mslorder  multiplexed  on  one  SBC  in  cluster  2. 

3.)  Process  trkdetec  on  one  SBC  and  process  msltrain  on 
another  SBC  in  cluster  1,  and  process  trkrprt  on  one  SBC  and 
process  mslorder  on  another  SBC  in  cluster  2. 

The  Link86  Input  option  was  used  to  link  cluinit, 
trkdetec,  msltrain,  and  gatemod  into  ClUSERS;  c2uinit , 
trkrprt,  mslorder,  and  gatemod  into  C2USERS  for 
constellation  1.)  and  2.)- 

For  constellation  3.)  following  linkage  was  done: 

trkdinit,  trkdetec,  and  gatemod  into  TRACKER, 

msltinit,  msltrain,  and  gatemod  into  MSLREACT , 

trkrinit,  trkrprt  ,  and  gatemod  into  REPORTER,  and 

msloinit,  mslorder,  and  gatemod  into  MSLORD. 

This  demonstration  program,  even  though  done  by  one 
person,  was  built  under  a  simulated  lead  programmer  team 
policy.  The  lead  programmer  provided  the  system-wide  shared 
data  declaration,  the  system  definitions,  the  cluster 
specific  relation  data,  pointer  assignments,  and  systems 
initialization.  The  lead  programmer  also  decided  about  the 
distribution  of  the  different  modules  over  the  system. 

The  application  programmers  built  their  modules 
%including  the  share. del  and  pointer. ass  files. 
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***        CIUSERS.IN?  file  *** 

#9(c:(c_ ___>ic:^:;: 

««*  This  file  is  used  to  link  user  initialization,  '^'^'* 

***  user  DTOcess  msltrain,  user  process  trkdetec,  and  *** 

***  ^atemodule  into  C1USERS.CMD.  the  executable  file  *»='* 

***  multlplexins  the  two  user  nrocesses  on  one  SBC.  '^'^'^ 

%f#  -J^  aA«  ikV  ^^  •V  ^*  ^  '^f  ^^  ^**  "'•*  ^f^  *V  V''  ^f  '*^  oA*  ^'^  «^  *V  •V  *"'  ^i^  *^  *^  4^  4^  ^^  V^  V>  *J*  ^  V*  ^1^  ^'^  ^  ^'  V#  ^^  ^^  *^  *ft  'ft  "4^  ^*  V#  ^V  '^  V^  *>V  ^V  ^'^  >V  V'  *^'  *V  "J^  *^  ^A' 
v^  ^1*  »f»  *{*  #^  --i^  ^y*  ^  a^  «^v  #f«  ojv  v^*  ^^  't^  *t^  1"  ^*  ^1^  ^\*  *r  'r  1*  O*  ''^  ^*  *^  ^^  *t*  *^  ^*  *t*  'I*  ^V*  *i*  *i^  ^T  T*  '^  ^^  'f*  ^C"  ^f*  *r  ^^  1^  "t^  t^  '^  ^r  ^1*  in  ^^  *r^  *^  'i*  'n  'P  'V^  f^ 


clusers   = 

cluinit    [code  [ab  [4:39]]  .data  [ah[800l  ,m[0]  ,ad[82]l  ,maD[alll]  , 

trkdetec , 

msltrain , 

eatemod 


'■-**  CIUINIT.PLI  file  -*- 

>!«>;e>le_ _____5ie:{«35s 

***  This  is  the  initialization  Drocedure  for  the        *** 
'■•'-■"'■^  multiDlexed  user  constellation.  ^"^-^ 


cl_users_ini t :   procedure  options  (main); 
%include  'sysdef  .pli  '  ? 


/*  bee;in  '^Z 

/*    trkdetec   */ 
call    create_proc    {'05'b4,    'fc'b4, 

'09eb'b4,     '0800 'b4.     '0029'b4, 
'0439'b4,     '0e00'b4,     '0S00'b4); 

/*  msltrain  */ 
call  create_proc  ('06'b4.  'fc'b4, 

'0a0b'b4,  '0800'b4,  '02^5'b4, 
'0439 'b4,  '0800 'b4,  '0800 'b4); 
call  await  {'fe'b4,  '01'b4); 
end  cl  users  irit; 
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***  TRACKER.  INP   file  *=*'' 

>;«** >>:^^ 

***  This  file  is  used  to  link:  trlcletec  initialization,  '===^''' 

***  user  process  trkdetec,  and  ^atemodule  into  *'^* 

**'!*  TRACKER.CMD,  the  executable  file  for  user  iDrocess  =^=«==^ 

***  trkdetec  in  the  non-mult  iDlexed  constellation.  "^"^-'^ 

***  sjc  j^e  ;ie  ;;s  s;;  >^  #-! -t  :}e  *  >j:  s;:  sje  xe  J^i  :}£>•,««  3)t :;:  3S£ :;::(:  :je  :^  jjt  :(e  jjc  #  3}c  jjt );« <t  >)c  >;s  >;«  jjc  ^ 

tracker  = 

trkdinit  [code  [ah  [4391 ] ,data [ab[800] ,m[0] ,ad [82] ]  ,map[all] ] , 

trkietec , 

gatemod 

--'-  TRKDINIT. PLI  file  *^''- 

^t9;c);c <«>X5? 

***   This    is    the    initialization    iDrocedure    for   user  '^'^'•^ 

***  process   trkdetec   in   the   non-.nultiplexed  **"' 

***   constellation.  "^"^"^ 

5|C  *f  5,*  ^j .  «|(  5|*  *JC  »J5  ^,C  5j€  ^^ .  TJC  Jj*  », '  *(^  3,*  »jC  ^(%  *('  ^C  5|"»  5J5  *|^  ^^  5(C  5|»  3^  igC  3jC  3p  ^,C  ?JC ?|«  5^  «f«  5/C  9yC  iJC  J,?  ^|t  )yC  i,i  5JC  ^^  "  2JC  »^  5JC  ^p  «f*  ^|n  «^  r^  3^  ^^  •■,«.  ^  rfi  ?JC  *|« 

trkiinit:    procedure  options  (main); 

%include  'sysdef .pli '; 

/*  beffir  */ 

call  create_T)roc  ('01'b4,  'fc'b4, 

'085d'b4,  '0800'b4,  '0023'b4. 

'0439'b4,  '0800'b4,  '?300'b4); 
call  await  ('fe'b4,  '31 'b4); 

end  trkdinit; 

*-*  MSLREACT.IMP   file  **- 

*** — J^ts;:^ 

***  This  file  is  used  to  link  msltrain  initialization,  "=*'='= 

*^=*  user  DFocess  msltrain,  and  ^atemodule  into  **"-" 

-'!'-  MSLREACT.CMD,  the  executable  file  for  user  process  --* 

***  msltrain  in  the  non-mult  iDlexed  constellation.  "^"^"^ 

0^  »f*  *l^  ^|«  ^1^  «^  vf«  «|*  r^   «^  ^|W  ^1^  r^   rf^  »!»  »|*  •,*  ^^  ^-^  ^f»  •'i*  ^^  *|»  »f"  »^  *^  ^^  "^  •l^  *l*  •!»  *T»  »!•  ^*  •^  ^^  ^»  *f*  •^  ^^  ^^  ^f*  ^1*  *^  ^^  ^^  ^^  ^p  ^^  w^*  ^p  »|«  »|«  ^^  ^^  ^^  *^  »|*  *^*  *^ 

nslreact  = 

msltinit  [code [a b  [439] ] ,data[ab  [830] ,m  [0] .ad [82] 1 ,maD[allll . 

msltrain , 

satemod 
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***          MSLTINIT.PLI  file  -** 

*>?* *:)t* 

***  This  is  the  initialization  procedure  for  user        '^'^^ 
'•"**  process  Tisltrain  in  the  non-iiultiplexed  ^^-''^ 

***  constellation.  *"">' 

?;«:{<  ^s  >[e  >;:  )[c :;::;« sjs  ;^  y.«  ^,«  ;;<  y,< :;« ^"^  >;«  ste  sjs  >;e  >^  >;<  5;c  3;e »;« ;Je  >;«  :;e  sic  ^  ;J«  ^ :{« j;«  sis  y,s  :{c  s;«  5;e  s*^  sjc  :^.c  :{s  ^ );« ^ 

msltinit:   procedure  options  (main); 
%include  'sysdef  .Dli  ' ; 


/*  begin  */ 

call  create_proc  ('02''b4:,  'fc'"b4:» 

'0825'b4,  '0900'b4,  '0023'b4, 
'(^439'b4,  '?800'b4,  '0e00'b4); 
call  await  ('fe'b4,  '01'b4); 
end  msltinit; 

s;:  3{c  :(t  s;<  ;;<  s;e  *  s;<  s;;  ;^  sis  St:  *  j^t  5?  « :p  s^t  #*  j;j  s)e  sic  sje  5;«  sit  **  :^  sf:  :;e  #*  j{e  3}e :«« Jt«  tX  **************  5!s  ^^ 

3|C  #|«  #|C  3|«  J^  *^  »|C  »|*  rf«»i^  *(*  •^^  *|S  ^,«^%  ^1*  «Y*  '^  ^i'  *i*  'i^  *i*  't'*  'i"*  *i*  *i*  *»*  "l^  "'i^  ^*  •!*  'I****  "1*  »Jt  ^|C  «^  *^  *|C  ^*  «|t  *,»  ^*  5|S  «p  ^i**  7|C  TJC  3|«  5,»  a^  ^*  ^|«  *|%  «^  ^s  . ,»  3J»  *k»  *[£ 

**=««          TF.KDETEC.PLI  file     R.  Haeger,  Dec  1985   '«'*- 
*** *** 

-c*-:  This  is  the  PL/I-96  code  for  user  process  tr.'Cdetec.  =^** 

***  It  simulates  track  detection  by  incrementing  track  '"■'** 

***  position  values  every  iteration.  It  Droduces  sha^'ed  **=** 

--*  data  TRACK.  -** 

*s;::;s*xc*s;c:(s»;ss;cs;c:is:(c;;:s;cs;cs;::^sie*s!cstc:;:*sic:(c*:;c:i:*;;csic*  *]((** ;X *******  *************** 
*********s^  **************:{$**********************  ************* 

trkdetect:   procedure  » 

^replace 

infinity        by  32767, 
one  by  '0e?l'b4, 

talen  by  50; 

%include  'sysdef .pli  ' ; 
%include  'share. del'; 

/*  used  shared  data: 

1  track(0:49)  based( tr_ptr ) , 
2  X  fixed  bin  (15) , 
2  y  fixed  bin  (15) , 
2  z  fixed  bin  (15) ,     */ 
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DECLARE 

i  fixed  bin  (15), 
(k,ta_ub,ta_lb)  bit  (16) , 
1  local_track, 

2  X  fixed  bin  (15). 

2  y  fixed  bin  (15) , 

2  z  fixed  bin  (15); 

/*  main  */ 

%lncliide  'pointer,  ass '; 

do  i  =  0  to  infinity; 

/*  simulation  of  track:  input  data  -^ / 
local_track.x=i+i; 
local_track:.y=i  +  10; 
local _track.z=i+i; 

/*  put  track  in  shared  memory  */ 
track:(Tiod(  i  ,  to  len  ) )  =  local_track:; 
call  advance  (TRACK_IN); 
tq_ub  =  read(TR^CK_IN); 

/*  disDlay  track  values  */ 

put  5kip(2)  edit  ( ^Track  '  .binary^ ta_ub ) , 

x:  ' , local_track.x, 
y:  ', local_track .y , 
z:  ' , local_track  .  z  , 
put  in  Queue  slot  '  ,mod ( i  ,  talen  ) ) 
(4(a,f(5))); 
ta_lb  =  read  (TR*CK_OUT); 

/*  report  status  */ 

put  skip(2)  edit('Last  consumed  track  '  ,binary( ta_lb  )  , 
'  in  slot:  ' ,mod ( birary ( tq_lb )-l , to len ) ) 
(2(a,f(5))); 

/*  check  if  slot  available  for  next  iteration  '"/ 
if  (  (  binary(  ta_ub)-"binary (ta_lb)  )  >=  talen  )  then 
do; 

k  =  add2bitl6( ta_lb,one); 

/*    report    status    */ 

put   skip(2)    edit    ('Waiting  for   slot:    ', 

mod(binary(k)-l, talen), 

to  be  consumed  ')  (a.f'.3),a); 
call  await  (TRACK_OUT,  k); 
end; 
end;   /*  do  FOREVER  */ 

end  trkdetect; 
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**«  MSLTRAIN.PLI  file     R.  Haeger,  Dec  1985   **- 

^:lr^ _— _— __^— — — _— »_  ■____„— ^-._——_^^_— :;i:4e9(c 

**'^'  This  is  the  PL/I-86  code  for  user  process  msltrain.  *''*=*' 

»:<*«  It  simulates  missile  launcher  training  by  -  'i'** 

>!«**  fiispiaying  launcher  assie;nment  and  direction  values.  '^^'^ 

«**  It  consumes  shared  data  MISSILI_ORDER .  *** 

^U  V^  V^  0^  V«  ^"^  ^'  «V  «^  v*'  ^^  V^  V*  V'  «V  V^  *^*  *•**  V'  ^^  ^'^  *^  ^V  ^V  4^  V'  V#  ^V  «V  *''*  ^f  «V  ^iV  * V  V^  V^  •"^  V^  >*'  ^*'  V^  ^^  ^^  ^^  V'  ^*'  *V  ^'  V^  ^A*  ^*  *V  ^^  ^''  V'  *''  *V  "^  ^''  ^' 

d^  f^ffi   7^  «^  «>p>  ^p  tf,i  rf«  Jp  iF^'^   ^^o    ?f*  c^  >|t  *p  ^p  ^«  ^f,  ^  J^    fi]fr  ^fr*f  ijf  S^  S^  i^  rp  4^    ^^if>  ^fi  f^  ?t«  «^  J^  ^«^p  ^^  #^  f^  r^  9f*  ^1^0^  «f>«^  «yk  a^  «^  #1*  ^i^  ^*  ^f»^ji  ^fi,  «p  ^« 

Xe  :tc :(!:{:  j{e  #  ^ :{( :^  )ic  >ie  sic  :;«>;;  X(  >>(:ie  n^ :}:  :tc »;:  3ic  9te  :)(#  3(c  ^  J*:  >i<  #  9(c  9((  ^  94e  ^  >}:3ic  ^t^  ^  ^  ^  ^  >r  ^  ^  >;(##  3t(  >^ 

msltrain:    procedure  ; 
%replace 

infinity     hy  32767, 
one  by  '0001 '"b4:, 

moqlen       by  50? 

%include  'sysdef .Dli '; 
^include  'share. del'; 
/*  used  shared  data: 

1   miss ile_order ( 0:49)    based (mo_ptr) , 
2    launcher    fixed   bin    (7), 
2   azimuth   float    binary, 
2   elevation    float    binary,  */ 

DECLARE 

i    fixed   bin    (15 )  , 

k   bit    (16)    static    init    ('0000'b4:); 

/*   end    DECLARATIONS    '^Z 

/*   main  */ 

%include  'pointer . ass '; 

do  i  =  0  to  infinity; 
k  =  add2bitl6(lr,  one); 

/*  report  status  */ 
put  skip  list ( 'msltrain  waiting'); 
call  await  (MISS ILE_ORDER_IN ,  k); 

/'^   consume  and  display  missile  order  values  */ 
put  skip(2)  edit ( 'launcher:  ', 

missile_order 'mod(i,moalen))  .launcher  , 
launch:  ',binary^k), 
azimuth:  ', 
missile _order(mod(i, moqlen) ) .azimuth, 
elevation:  ' , 
missile  or der (mod (i, moqlen) ) .elevation) 
(2(a,fr5)),2(a,e(10,2))); 
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call  advance  ( MI SSILE_ORLER_OUT ) ; 
end;   /*  do  i  */ 
end  msltrainJ 


:«c*«:;c  #  j<«  sjs  3^  >je5f:)jc«****>}t*«*  *#*«'!<**«*  ^J^t^^Jjc***  J?  3«t**:«t«*3«e*X«3<t***«  see's:* 

***        C2USIRS.I.MP  file  -^''^ 

***  This  file  is  used  to  link  user  initialization.  *-- 

***  user  process  mslorder,  user  process  tricrprt,  and  "^"^'-^ 

***  gatemodule  into  CSUSERS .  CMD ,  the  executable  file  -='==!' 

*sis*  multiplexing  the  two  user  processes  on  one  SBC.  '^'^''* 

cEusers  = 

c2uinit  [code [ah [4391] .data [ab [800] .m[e]  .ad  [92] 1  ,maprall|]  , 

mslorder , 

trkrprt, 

satemod 

:if.tf.-i(.^:!f.'ili-if.yi-!liiifi-iiii'^if.-ifi-i^i{:ili-if.-if.i(.if.^:i!i-if^:ff.i^^ 

m  C2UINIT.PLI  file  --=^ 

ti^if.   This  is  the  initialization  procedure  for  the         '^"^^-^ 
***  multiplexed  user  constellation.  '^-'^'^ 


r2_users_init :   procedure  options  (main); 

^include  'sysdef  .pli  ' ; 

/*  he^in  */ 

/*   missile   order    "^f 
call    create_proc    {'03't4,    'fc'D4, 

'0a29"b4,     V800'b4.     'e029'b4. 
'0439 'b4.     '0P00'b4,     '0630 'b4); 

/*    track:   report   */ 
call    create_Droc    ('04'b4,    'fc'b4. 

'0b47'b4.     '0P03'b4,     '0303 'b4, 
'0439 'b4.     '08,00 'b4,     '0303 'b4); 
call   await    ('fe'b4,    '01'b4); 
end    c2_users_init ; 
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'!'**        REPORTER.  IN?  file  --=^ 

***  This  file  is  used  to  link:  trlcrrrt  initialization,  *** 

***  user  process  tricrprt,  and  gatemodule  into  "•^*'^- 

***  REPORTER.CMD,  the  executable  file  for  user  process  -*- 

***  trkrprt  in  the  non-multiplexed  constellation  *** 

o«  Jf  OU  uu  *4^  aJU  «t*  *''  ^^  ***  ^**  **'  V^  ^^  ^**  ^''*  ^l'  ^'  ^*  ^'^  ^-'^  V*  ^'  *^  ^*  ^^  V^  ^V  ^V  *^  •V  ^'^  W  *f^  «"'  V^  ^i^  ^V  ^f'  «''  ^«  "^^  ^'^  ^^  *^  ^^  ^^  *^  v^  ^''  «"*  ^'  ^'  ^**  ^'^  «''  V'  «''  ^#  ^^ 

*V^  "l^  *4*  ^^  I*!*  ^*  ^»  »|*  *i*  ';*  *r»  *t*  ^  ^*  *!*  I**  ^^  •^^  "4*  •!*  •H*  *if*  -^^  *^*  ^^'^  •^  ^|f»  *^  ^1*  *|*  "l^   *(•  ^^  S)*  (^  ^^  o|«  v^  «^  vfh  ^ik  *-,«  «>|v  *4*  ^«  #1%  «p  #y«  ^fr  ^^  «|«  ^|«  #^  ^f^  0^  «^«  7|«  ^^'^  «^%  «|S 

reporter= 

trkrinit    [code [ah [439] ] ,data [ah  [B00l ,m[0l ,ad[S2]] ,maD[all]]  , 

trkrprt , 

satemod 

V:iili■!i^iiiii!ii:~V)i■i}i^/|i:(liif■ifiifii\^tii\<^^i'i^■>\it<^tf^ 

***          TFKPINIT.PLI  file  >?** 

«** **« 

***  This  is  the  initialization  procedure  for  user        *=^* 
**x<  process  trkrprt  in  the  non-multiplexed  cons  tellation  .**'=*=* 

trkrinit:   procedure  options  (main); 

%include  'sysdef  .pli '; 
/*  he,y:in  */ 

call  create_Droc  ('<^4'h4,  'fc'h-i, 

'087f'h4,  '0800'h4,  '0023'b4, 
'0439'h4,  '?e'^e'b4,  '?60e'b4); 

call  await  ('fe'h4,  '01 'h4); 
end  trkrinit; 

sic«>;<  MSLORD.INP   file  -'='* 

yf-   yp   *f>    ^_     ■■—  ■■    ••-  ^H«n>  ^~^B    «^«B    «V  «^  ^B  MM  BOB  m^  ^B    _^  .^  ^M  ^IB  *^  ^»  (^  SMB  S^  ^M  O^  W  MB    a^    ^B  ^B  (^  ■■»  ^IB  M  MM*    ^^  SV  ^H  ^B    MM  ^B  ^B  a^  ^M  S^  «H*  ^^  MW  ^BB  ^B  ^M  ^1^    •j^    ^P 

**'!•  This  file  is  used  to  link  mslorder  initialization,  **'=* 

*'^'*  user  process  nslorder,  and  ^atemodule  into  ^'^^ 

^'-^"^   MSLORD.C^D,  the  executable  file  for  user  process  "^"^"^ 

***  mslorder  in  the  non-multiplexed  constellation.  -'-^'-^ 

T*  35*  "T*  T*  '*■"  *1*  "l^  *T*  •?*  •?  ^*  ^C  T*  t'  *?  *l*  *"»*  *3*  *?  •P  'P  ^^  'I*  *P  •?*  't^  *?  •Q"  ^P  •?  'P  *t*  ^?  n*  *^  *!*  •%*  *l*  T^  1*  ^i*  '^  n^  *!*  •?*  *l^  *P  "P  T*  *^  1*  *■!*  *?*  '1*  ^*  ^1*  *!*  T*  *^  T* 

mslord  = 

msloinit  [code  [ab  [439]  1  , data  [ah  [300]  ,m  [0]  ,ad  [S2]]  ,maT)[all]  ]  , 

mslorder, 

^atemod 


102 


>jc  ;(e  >!c  5!e «  jje  #  >je  >}c  *  >!c  >}t -t  :;e  :je  xe  ********  >}t  5>:  5>:  >>«*  s{t  ****  >;c  3jt  «>)'*«  s^t  =>t '■^  >:« 'i*  >>:*  <^ 
*********:<<*  >;;j{c***j}e*j;c****«j;ej{c^;{c}^:;c******]«c***********>;:**^:****V*** 

***          MSLOINIT.PLI  file  ^•'*''-' 

*** *** 

***  THis  file  is  the  i  rtializat  ion  Droced^ire  for  user  -'^'^ 
***  process  Tislorder  ia  the  non-7iul  ti  plexed  c  onstellat  ion"=''* 
******************************************************* w*** 

msloinit:   Drocedure  oDtions  (-nain); 
%include  'sysdef  .pli  ' ; 

/*  be^in  */ 

call    create_Droc    ('03''b4,    'fc'b4, 

'09h3'"b4,  '(^e^e't^:,  '0?23'b4, 
'0439'b4,  '0P00'b4,  '0800'b4); 

call  await  ('fe'b4,  '0l'b4); 
end  msloinit; 


************************************************************ 

********$;:**  *:^>;cX<*  *************************************  ******* 

***       TRKRPRT.PLI  file      R.  Haeeer,  Dec  1985      --* 
*** *** 

***  T^is  i5  the  PL/I-86  code  for  user  process  trkrprt.  '^'^'■^ 

***  jt  simulates  comDutation  of  delta  values  for  tractcs  '*=='"'' 

***  by  comparing  two  consecutive  positions  of  a  trac::C.  '^'■*'^ 

***  It  consumes  shared  data  TRACK  and  produces  shared  '^'^^ 

***  data  DELTA.  --'!' 

****************************;(«****:;(*:;:);(  *:(:*:;c**  ***************** 

trkrprt:    procedure  ' 

^replace 

infinity  by  32767, 

one  by  '0?01'b4, 

da len  by  20 , 

talen  by  50; 

^include  'sysdef .pli  ' ; 
^include  'share. del'; 

/=<*  used  shared  data: 

1  track:(0:49)  based(  tr_pt  r  )  . 
2  I  fixed  bin  (15) . 
2  y  fixed  bin  (15) . 
2  z  fixed  bin  (15) , 
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delta(0:19)  based (de_Dtr ) , 

2  dx  fixed  bin  (7) , 

2  dy  fixed  bin  (7) . 

2  dz  fixed  bin  (7) ,   */ 


DECLARE 


i  fixed  bin  (15), 

(km,k)  bit  (16)  static  init  ('0000'b4:), 

(dq_ub,dq_lb)  bit  (16). 

1    local_tractc, 

2  X  fixed  bin  (15) , 
2  y  fixed  bin  ( 15) , 

'waiting  for  slot  ', 
mod  (binary  (k:  )-l  ,dq  len  ) , 
'  to  be  con        2  dy  fixed  bin  (7), 
2  dz  fixed  bin  (7) ; 

/*  end  DECLAHATIONS  */ 

/*  main  */ 

%include  'pointer. ass '» 

do  i  =  0  to  infinity; 

/*  report  status  */ 
put  skip(2)  list  ( 'proc  trkrprt,  iteration:  ', 

i,  '  wait ing  ' ) ; 

km   =   add2bitl6(km ,    one); 
call    await    (THACK_IN,    km); 
/*   report    status    */ 
put   list (  '  going    ' ) ; 

/*   read   shared  data   item  and   compute   delta   values   */ 

local_delta.dx=(track(mod(i,tQlen)).x)-(local_track.x); 
local _delta.ly=^  track (mod (i,talen) ) .y)-(local_track.y); 
1 ocal _delta. dz= ( track (mod (i, to len) ) .z )-(local_track.z); 

/*   display   computed   delta   values    */ 
put   skip   list('   Ix: ' , local_delta .dx , 

dy: ' , local_delta.dy , 
dz :' .local _d el ta  .dz  ) ; 

/*    save    track  data    for   next    iteration   */ 
local_track=track(mod(i,talen)  ) ; 

/*   put    delta    in   shared   memory   */ 
delta (mod( i ,dalen) )=local   delta; 
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call  advance(DELTA_IN) ; 

/*  report  status  */ 
Dut  list(  '  done  ') ; 

iq_ub=reai (DELTA_IN ); 
dq_lb=read(DELTA_OUT); 

/*  check:  if  slot  available  for  next  iteration  */ 
if  (  (binary{la_ub  )-'binary(dq_lb  )  )  >=  dqlen)  then 
do; 

k=add2bitl6(dq_lb,one); 

/*  if  queue  is  full,  report  status  */ 
put  sk:ip(2)  editv'Delta  queue  full,^', 

'waiting  for  slot  ' , 
mod(binary(k)-l,dqlen) , 
to  be  consu'red') 
(a.a.f  (3),a); 

call  await(DELTA_OUT.k); 
-  end; 
end;   /*  do  i  ''^ / 

end  trkrprt; 


***  MSLORDER.PLI  file    P..  Hae^er,  Dec  1965  =^-=^ 

***  This  is  the  PL/I-36  code  for  user  process  mslorder.  ^'^'^ 

***  It  simulates  computation  of  missile  launcher  '^'^'^ 

■^"^•^  direction  and  launcher  assignment.  =^=^''^ 

***  It  consumes  shared  data  TRACK  and  EELT\,  and  *'^=«= 

***  produces  shared  data  MISSILE_ORDER.  --=^= 

•I*  •>'  n*  'i*  *t*  T"  ^*  '^  ^.*  'i*  'I*  ^  *t*   'i"  ••^  *»*  *i*  *!*  'r  *^  *(*  *r  't*  *?  *>*  '(*  *»^  ^»*  T*  '^  ^5*  ^i*o'^  *!*  *<*  't^^i*  TT  *l*1*  A^  ^''  *!*  *i^*Tn  '^'  ^'?  *¥*  *t*  *?•  'P  'i^  'I*  t^T*  ^^'?  1*  5?  '»* 


mslorder:    procedure 
:^replace 


infinity  by  32767, 

one  by  '0001'b4, 

tqlen  by  50, 

dqlen  by  20, 

moolen  by  50; 


:Sinclude  'sysdef  .  pli  '  t 
^include  'share. del'; 
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/*  used  shared  data: 

1  traclc(0:49)  based  ( tr_ptr  ) , 
2  X  fixed  bin  (15) , 
2  y  fixed  bin  (15) , 
2  z  fixed  bin  (15) , 

1  delta(0:19)  based(de_ptr ) , 
2  dx  fixed  bin  (7). 
2  dy  fixed  bin  (7), 
2  dz  fixed  bin  (7) , 

1  missile_order(0 :49)  based(mo_ptr  ) , 
2  launcher  fixed  bin  (7), 
2  azimuth  float  binary, 
2  elevation  float  binary,   "^f 


DECLARE 


i  fixed  bin  (15) , 

km  bit  (16)  static  init  ('000?'b4), 
kd  bit  (16)  static  init  ('0000'b4:), 
;moa_ub,moq_lb )  bit  (16), 

1  loral_track: , 

2  X  fixed  bin  (15)  , 

2  y  fixed  bin  (15)  , 

2  z  fixed  bin  (15)  . 

1  local_del ta  , 

2  dx  fixed  bin  (7) , 
2  dy  fixed  bin  (7) , 
2  dz  fixed  bin  (7) , 

1  local_order, 

2  launcher  fixed  bin  (7), 
2  azimuth  float  binary, 
2  elevation  float  binary; 

/*  end  DECLARATIONS  */ 

/*  main  */ 

%include  'iDointer  .ass '; 
do  i  =  0  to  infinity; 

/*  report  status  */ 
put  skip(2)  list('proc  mslorder,  iteration:  ', 

i ,  '  m_wai tin^  ' ) ; 

kd=add2bitl6(lrd,one)  ; 
call   await (DELTA   IN,kd); 
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/*  report  status  */ 
put  list (  '  ^_soinz    ' ) ; 

/*  copy  track  values  */ 
lo ca l_track  =  t rack (mod (i ,tqlen)  )? 
call  advap.ce(TRACK_OUT); 
/*  CODY  ielta  values  */ 
local_delta=delta(niod(l  ,dalen)  ); 
call  advance  (DELT-A_OOT)i 
/*  display  track  values  */ 
put  skip  list('  x:  ' ,  local_track.x ,  '  y :  '  ,local_track .y , 

z :  '  ,local_track  .  z  ) ; 
/*  assign  launcher  */ 
local _order .launcher=mod ( i ,4)+i; 

/*  simulate  direction  coT'Dutation  =^/ 
local _order.azimuth= 

atand ( float ( local  track. y  +  localdelta . ay ) / 
float ( local_track  .X  +  local_ del ta  .dx  )  j  ; 
local_order  .elevation= 

atard( float ( local_track. z  +  local_ delta  .dz  )/ 
float (local_track  .X  +  local_del ta  .dx)  )  ; 
/*  put  missile  order  in  shared  memory  '^V 
missile_order(mod(i,moqlen))=local_order; 
/*  display  missile  order  values  */ 
put  skip  list('  1 :' ,local_order. launcher, 

a: '.local_order. azimuth, 
e: ', local _order .elevation  )  ; 
call  advance(MISSILE_ORDER_IN); 

/*  report  status  */ 
put  list(  '  m_done  ' ) ; 

moa_uh  =  read (MISSIIE_ORDER_I N ) ; 
moq_lh  =  read  (MISS ILE_CRDER_OUT) ; 

/*  check  if  slot  available  for  next  ireration  ="/ 
if  (  (hina  ry  (moq_ub  )-'binary(moa  _lb  )  )>=moalen  )  then 
do; 

km  =  add2bitl6(moq_lb  ,  one  ) ; 
/*  report  if  queue  is  full  */ 
put  5kip^2)  edit ( 'Missile_order  queue  full,  '. 

'waiting:  for  slot  ', 
mod ( binary ' km )-l ,moql en  ) , 
'  to  be  consumed  ' ) 
(a,a,f (3)  ,a); 
call  await  ( MISSILE_ORDER_OUT .  km); 
end; 

end;   /*  do  i  */ 

end  mslorder; 
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APPENDIX  F 
SYSTEM  INITIALIZATION 

To  switch  on  and  initialize  the  system,  follow  these 
steps : 

(1) 

Switch  on  and  set  up  the  hardware  components  of  both 
clusters  in  accordance  with  the  respective  power  on 
procedures  described  in  the  AEGIS  lab  up  to  the  point  where 
the  system  disks  are  in  their  drives  and  the  reset  button  of 
the  MULTIBUS  frame  was  pushed. 


(2) 


(3) 


Insert  MCORTEX  disks  for  cluster  1  and  cluster  2  in 
their  respective  drives. 

For  cluster  1: 

At  terminal  1  type  in:  capital  'U* . 

After  prompt  type  in:  'gffd4:4'  followed  by  RETURN. 

After  prompt  choose  console  '1'  and  login  disk  'B'. 

After  prompt  B>  change  to  disk  A. 

After  prompt  A>  type  in:  'Idcpm'. 

After  prompt  A>  type  in:  ' Idboot ' . 

After  prompt  A>  change  to  disk  B. 

After  prompt  B>  terminal  1  is  ready  for  MCORTEX. 

At  terminal  2  type  in:  capital  'U' . 

After  prompt  type  in:  'ge000:400'. 

After  prompt  choose  console  '2'  and  login  disk  'C'. 

After  prompt  C>  change  to  disk  B. 

After  prompt  B>  terminal  2  is  ready  for  MCORTEX. 

At  terminal  3  type  in:  capital  'U' . 
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After  prompt  type  in:  'ge000:400'. 

After  prompt  choose  console  '3'  and  login  disk  'D'. 

After  prompt  D>  change  to  disk  B. 

After  prompt  B>  terminal  3  is  ready  for  MCORTEX. 

For  cluster  2: 

At  terminal  1  type  in:  capital  'U' . 

After  prompt  type  in:  'gffd4:0'. 

After  prompt  do  the  same  as  in  cluster  1  after  this 

step. 

Make  sure  cluster  1  is  connected  to  the  RTC'-^'  Ethernet. 
System  is  ready  for  MCORTEX. 

(4) 

At  cluster  1: 

At  terminal  1  type  in:  'MCORTEX'  followed  by  RETURN. 

System  will  ask  for  global  memory  to  be  loaded,  type  in: 

•Y'  and  hit  RETURN. 

System  will  ask  for  filename. 

At  terminal  2  type  in:  'MCORTEX'  followed  by  RETURN. 

System  will  ask  for  global  memory  to  be  loaded,  hit 
RETURN . 

System  will  ask  for  filename. 

At  terminal  3  do  the  same  as  at  terminal  2. 

Cluster  1  is  ready  for  initialization. 

At  terminal  1  type  in:  'C1PR0C.CMD'  and  hit  RETURN. 

The  driver  will  prompt  with  length  of  longest  queue,  and 

signal  that  cluster  1  is  initialized. 

Cluster  1  is  ready  for  the  application  processes. 

Initialize  cluster  2  the  same  way  as  cluster  1,  but  type 
in:  'C2PR0C.CMD'  instead  of  'C1PR0C.CMD'. 
After  driver  prompts,  the  system  is  ready  for 
application  processes. 
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(5) 


(6) 


(7) 


Following,  the  initialization  of  the  demonstration 
program's  non-multiplexed  constellation  is  described. 

At  cluster  2: 

At  terminal  2  type  in:  'MSLORD.CMD'. 

User  process  MSLORDER  will  start  executing. 

At  terminal  3  type  in:  'REPORTER. CMD' . 
User  process  TRKRPRT  will  start  executing. 

At  cluster  1: 

At  terminal  3  type  in:  'MSLREACT.CMD'. 

User  process  MSLTRAIN  will  start  executing. 

At  terminal  2  type  in:  'TRACKER.CMD'. 

User  process  TRKDETEC  will  start  executing. 

The  total  system  will  run. 

Every  terminal  displays  respective  data  on  its  screen. 
Terminals  1  in  both  clusters  show  message  exchange 
activity  'transmitting'  or  'receiving'. 

To  stop  any  process,  hit  'Control  S'  at  the  respective 
terminal.  To  restart  the  process  hit  'Control  S'  again, 


110 


LIST  OF  REFERENCES 


1.  Brewer,  D.J.,A  Real-Time  Executive  for 
Multiple -Computer  Clusters ,  M.S. Thesis ,  NavaT 
Postgraduate  School,  Monterey ,  California,  December 
1984 

2.  Swan,  R.J.,  and  others, CM^  -  A  Modular 
Mult 1 -Microprocessor,  Proceedings  o^  the  National 
Computer  Conference~7  \^1T~. 

3.  Reed,  D.P.  and  Kanodia,  R.J.,  "Synchronization  with 
Eventcounts  and  Sequencers,"  Communication  of  the  ACM, 
Volume  22,  p.  115-123,  February  1979. 

4.  Wasson,  W. J . , Detailed  Design  of  the  Kernel  of  a 
Real-Time  Multiprocessor  OperarTng  System,  ""M . S . 
Thesis ,  Naval  Postgraduate  S^ooTt  Monterey, 
California,  June  1980. 

5.  Rapantzikos,  D.K. ,  Detailed  Design  of  the  Kernel  of  a 
Real-Time  Multiprocessor  Operating  System,  MTS . 
Thesis ,  Naval  Postgraduate  ScnooT^  Monterey, 
California,  March  1981. 

6.  Cox,  E.R.jA  Real-Time,  Distributed  Operating  System, 
M.S.  Thesis,  Naval  Postgraduate  School ,  Monterey , 
California,  December  1981. 

7.  Klinefelter,  S.G. , Implementation  of  a  Real-Time , 
Distributed  Operating  System  for  a  MuTti  Computer 
Sy s t em";  M.S'T  Thesis ,  Naval  FosTgraduate  School , 
Monterey ,  California,  June  1982. 

8.  Rowe,  W.R. , Adaption  of  MCORTEX  to  the  AEGIS  Simulation 
Environment!  M .  S  .  TKesTs";  N^vaT  Fos^tgraduate  School, 
Monterey,  California,  June  1984. 

9.  Xerox  Corporation, The  Ethernet  2.  A  Local  Area  Network: 
Data  Link  and  Physical  Layer  Specif icat ion, Version 
rrOT  Seprembei^l98DT  — 

10.  InterLAN  Corporation,NI3010  MULTIBUS  Ethernet 
Communication  Controller^Jser  Manual, 1982. 

11.  Digital  Research, PL/I  Language  Reference  Manual , 1982 . 


Ill 


INITIAL  DISTRIBUTION  LIST 


No.   Copies 


1.  Defense  Technical  Information  Center  2 
Cameron  Station 

Alexandria,  Virginia  22304-6145 

2.  Library,  Code  0142  2 
Naval  Postgraduate  School 

Monterey  California  93943 

3.  Department  Chairman,  Code  52  1 
Department  of  Computer  Science 

Naval  Postgraduate  School 
Monterey,  California  93943 

4.  CDR  Gary  S.  Baker,  Code  52Bj  1 
Department  of  Computer  Science 

Naval  Postgraduate  School 
Monterey,  California  93943 

5.  Dr.  Uno  R.  Kodres ,  Code  52Kr  3 
Department  of  Computer  Science 

Naval  Postgraduate  School 
Monterey,  California  93943 

6.  LCDR  Reinhard  Haeger  3 
Ostendstrasse  20 

4750  Unna-Massen 
West-Germany 

7.  Daniel  Green,  Code  20F  1 
Naval  Surface  Weapons  Center 

Dahlgren,  Virginia  22449 

8.  CAPT  J.  Donegan,  USN  1 
PMS  400B5 

Naval  Sea  Systems  Command 
Washington,  D.C.  20362 

9.  PCA  AEGIS  Data  Repository  1 
RCA  Corporation 

Government  Systems  Division 
Mail  Stop  127-327 
Moorestown,  New  Jersey  08057 

10.  Library  (Code  E33-05)  1 
Naval  Surface  Warfare  Center 

Dahlgren,  Virginia  22449 

11.  Dr.  M.  J.  Gralia  1 
Applied  Physics  Laboratory 

John  Hopkins  Road 
Laurel,  Maryland  20707 

12.  Dana  Small  1 
Code  8242,  NOSC 

San  Diego,  California  92152 

13.  Dokumentationszentrum  der  Bundeswehr  1 
Friedrich-Ebert-Allee  34 

5300  Bonn 
West-Germany 

112 


I 


Thesis  Thesis 
H1097   H1097 
c.l    c.l 


21GS1S 


Haeger  • 

Process  synchroniza- 
tion and  data  communi- 
cation between  pro- 
cesses in  real  time 
local  area  networks. 


26  HAr  ?9 


3  18  18 


Thesis 

H1097 

c.l 


2'.8G1S 

Haf^eer 

Process  synchroniza- 
tion and  data  communi- 
cation between  pro- 
cesses in  real  time 
local  area  networks. 


